failed to retrieve a transaction from klaytn node 오류 관련
안녕하세요, 다음과 같은 코드로 nft 를 전송을 하는데, const param = { from: from, to: this.shoeContractAddress, value: 0, input: await contractInstance.methods .safeTransferFrom(from, to, tokenId) .encodeABI(), gas: 1000000, submit: true, }; const tx = await this.caver.kas.wallet.requestSmartContractExecution( param, ); 다음과 같은 에러가 나왔습니다: 22-08-25 11:17:17 _code: 1065000, _message: 'failed to retrieve a transaction from klaytn node; failed to retrieve a transaction from node', _requestId: '719dcef8-11b1-4f7f-b5ab-85d739fcf38e' 그리고 나서 2초 정도 후에 실제 transaction 이 수행된 것으로 보입니다. https://scope.klaytn.com/tx/0x29c609761a543c21349c0b76b31d410cbdd63f0dbb19cb165ac8c0f32f54a32b?tabId=nftTransfer 그래서 혼란이 오는데, 1. requestSmartContractExecution() 에서 fail 이 나왔으면 transfer 도 안될 것으로 예상했는데, 그렇지가 않은가요? 2. 해당 에러는 언제 발생하는거고 의미가 무엇인가요? 3. 어떤 에러들이 추후 다시 tx 이 실행될 수 있는 에러들인가요? 비슷한 시간대에 다른 fail 난 requestId 들입니다: _requestId: '8ffbb8bb-e769-4505-b4af-4c80321a1de7' _requestId: 'b1cc2fe7-8405-45c3-8e47-d7d61197e9de' _requstID: '1b387ee5-945f-43eb-815f-178f90022f41' 감사합니다.
0
-
공식 댓글
답변이 지연되어 대단히 죄송합니다.
- requestSmartContractExecution() 에서 fail 이 나왔으면 transfer 도 안될 것으로 예상했는데, 그렇지가 않은가요?
- 해당 에러는 트랜잭션 fail이 아닌 노드에서 해당 transactonHash 조회시 못 찾았다는 것을 의미합니다.
- 해당 에러는 트랜잭션 fail이 아닌 노드에서 해당 transactonHash 조회시 못 찾았다는 것을 의미합니다.
- 해당 에러는 언제 발생하는거고 의미가 무엇인가요?
- 정확히는 트랜잭션을 보내고 해당 트랜잭션에서 받은 transactionHash값 조회시 해당 에러 응답을 가진 것으로 보입니다. 저 의미는 해당 TransactionHash가 해당 노드에서 받지 않았음을 말합니다.
- 일반적인 현상은 아니나 네트워크의 지연시 간혹 발생할 수 있습니다.
- 어떤 에러들이 추후 다시 tx 이 실행될 수 있는 에러들인가요?
- 일반적으로는 트랜잭션 보낸 후
const ret = await caver.kas.wallet.getTransaction(transactionHash)
조회시 블록에 쓰이기 전까진 Submitted가 나오고 쓰이면 Committed로 상태가 변경되는 것이 정상입니다. - 네트워크 지연 상황시 발생될 수 있어서 5번 이내로 retry해보는 것을 권장드립니다.
- 일반적으로는 트랜잭션 보낸 후
- submitted 상태에서 committed 될때까지 해당 tx 가 몇 초가 걸렸는지 어떻게 찾아볼 수 있나요?
- comitted는 consensus노드 상황과 여러 복합적인 이유로 정확히 예측은 없으며 따로 그런 통계자료는 제공되고 있지 않습니다.
- comitted는 consensus노드 상황과 여러 복합적인 이유로 정확히 예측은 없으며 따로 그런 통계자료는 제공되고 있지 않습니다.
- 이렇게 오래걸리는 경우들이 잦나요? (위와 마찬가지로 kas.requesetSmartContractExecution() 함수를 썼습니다)
- consensus 노드 합의, 네트워크 지연, 트랜잭션 부하 상황시 발생될 수는 있으나 일반적이진 않습니다.
- consensus 노드 합의, 네트워크 지연, 트랜잭션 부하 상황시 발생될 수는 있으나 일반적이진 않습니다.
- 해당 cancel tx 는 왜 성공하지 못하고 scope 에 남아있지 않나요?
- 해당 tx는 보내고 난 후 취소 전에 이전에 보낸 tx가 이미 Commit된 걸로 보입니다. 이 경우 cancel tx의 수수료는 따로 들지 않습니다.
Consensus노드 간 동기화의 이유로 결과가 바로바로 나오진 않을 수 있습니다.
따라서 commited상황 전까지 retry로 확인 부탁드립니다.
다만, node에서 해시를 찾을 수 없는건 일반적인 상황은 아니나 상황에 따라 발생될 수는 있으므로 exponential backoff로 재시도를 권장드립니다 - requestSmartContractExecution() 에서 fail 이 나왔으면 transfer 도 안될 것으로 예상했는데, 그렇지가 않은가요?
-
추가로 질문드리고 싶은게 있는데
0x814c0f3a1c236712e998d190101e22ed1ca904dd49a2209376777ca08cd3900e
경우 submitted 상태에서 5초 이상 시간이 걸려서 저희가 cancel을 날렸습니다.
cancel tx 는 다음과 같은데: 0x5cbd411cd3b367243a91f5590a2327621cd352a8cecb62b00683b92c0d3a9e6e
1. submitted 상태에서 committed 될때까지 해당 tx 가 몇 초가 걸렸는지 어떻게 찾아볼 수 있나요?
2. 이렇게 오래걸리는 경우들이 잦나요? (위와 마찬가지로 kas.requesetSmartContractExecution() 함수를 썼습니다)
3. 해당 cancel tx 는 왜 성공하지 못하고 scope 에 남아있지 않나요?0
댓글을 남기려면 로그인하세요.
댓글
댓글 2개