错误码及解决方案

本文针对常见的一些错误码提供解决方法以供参考。

说明

其他错误码可参见合约链错误码进行问题排查。

104

错误描述

英文:the sender of tx doesn't have enough money

中文:交易的发送账户余额不足

问题原因

给其他用户转账的金额大于本身拥有的余额。

例如:

  1. 使用tester001账户创建新的userIdentity账户,并给userIdentity账户转账100,此时新账户userIdentity中余额为100;

  2. 则当userIdentity账户给tester001账户转账200时,则会提示:交易的发送账户余额不足。image.png

解决方案

给其他用户转账的金额要小于本身拥有的余额,如果本身余额为0,则不能进行转账。可以通过查询账户的接口查询自己的余额。

image.png

110

错误描述

英文:basic tx type requirement verify failed

中文:基本的交易类型需求校验失败

问题原因

  1. 冻结用户账号from只能为admin或自身账号。

  2. 解冻账号from只能为admin。

  3. 冻结合约账号from只能为admin。

  4. 解冻合约账号只能为admin。

解决方案

下列截图中通过前面红框中的账号(from)操作后面红框中的账号(to)。

  1. 冻结用户账号

    使用admin进行冻结image.png自己冻结自己:

    image.png

  2. 解冻用户账号

    image.png

  3. 冻结合约账号

    image.png

  4. 解冻合约账号

    image.png

116

错误描述

英文:the source account of tx doesn't exists in blockchain

中文:交易的提交账户在区块链上不存在

问题原因

交易数据结构中的 from 字段的提交账户不存在。

解决方案

调用查询接口传入账号ID检查账户是否存调用查询接口传入账号ID检查账户是否存在、检查配置的链ID是否正确。

image.png

修改from

image.png

118

错误描述

英文:the source account of tx is frozen

中文:交易的提交账户已冻结

问题原因

账户被冻结。

解决方案

使用Administrator解冻from账户。

image.png

119

错误描述

英文:the source account of tx is recovering

中文:交易的提交账户正在恢复中

问题原因

原因:账户操作预重置公钥后,发起交易。

如下图, 执行完preResetPubKey不执行resetPublicKey,账户状态为RECOVERING,在使用这个账号进行交易就会报错

解决方案

执行完preResetPubKey()操作后,需要继续执行resetPublicKey()操作,再发起交易。

image.png

120

错误描述

英文:the dest account of tx doesn't exit in blockchain

中文:交易的目标账户在区块链上不存在

问题原因

交易数据结构中的 to 字段的目标账户不存在

解决方案

修改to账户名称,且要保证存在。

image.png

说明

可调用查询接口查询传入账号ID检查账户是否存在。

重点关注主链和子链是否设置错误。

image.png

121

错误描述

英文:the dest account of tx is frozen

中文:交易的目标账户被冻结

问题原因

目标账号被冻结。

解决方案

使用Administrator解冻userIdentity账户。

image.png

122

错误描述

英文:the signature of tx is not enough

中文:交易签名不足​

问题原因

多签名的所有签名权重之和小于 100,平台要求必须大于等于 100。

解决方案

  1. 先检查自己账户的权重是否大于等于100,可以调用查询账户的接口查询,在返回的结果AuthMap中,给value求和是否大于等于100。

    image.png

  2. 如果不够,可以修改AuthMap,调整对应的权重大小。

    image.png

  3. 然后在SDK启动时,将对应的私钥设置进去。

    例如创建一个用户,两个key的权重分别为90。

    image.png

    但是SDK启动时,只配置一个key,则该账户发起交易时则会提示权重不足。

    image.png

123

错误描述

英文:the dest account of tx already exist

中文:交易的目标账户已经存在

问题原因

解决方案

创建了两个同名账号account、则会提示:the dest account of tx already exist。

image.png

修改要创建账号的id。

408

错误描述

英文:transaction verify failed

中文:交易验证失败

问题原因

以下为query transaction receipt的返回结果,errorCode返回了408(transaction verify failed),表示查询交易收据失败

{
        "isSuccess": false,
        "data": {
                "transactionReceipt": {
                        "result": 123,
                        "gasUsed": 0,
                        "logs": [],
            "output": [2,5,2,2,4,5,6,7,8,9,4,3,4,5,6,7,8,3]
                },
                "bockNumber": 0,
                "index": 0,
                "sequenceId": 74,
                "errorCode": "SERVICE_TX_VERIFY_FAILED",
                "groupId": {
                        "data": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
                },
                "LOGGER": {
                        "logger": {
                                "name": "mychainv10"
                        }
                },
                "messageType": "MSG_TYPE_QUERY_RESP_TRANSACTION_RECEIPT"
        },
        "txHash": "5c300eabaca0cf49198f0981cbac903fd90b3ca67ec9fd043b4a27f1c51c2817",
        "errorCode": "408"
}

解决方案

当外层errorCode返回408时,此时需要再看一下transactionReceipt中result值是多少,比如以上例子中,result=123(the dest account of tx already exist),即账户已存在。

如果仍然无法定位原因,可以将transactionReceipt中的output数组直接放在new String()中转化为打印出来查看。

2003

错误描述

英文:the payload of transaction is invalid

中文:创建或者更新账户时,交易内容不合法

问题原因

1.创建用户修改了version

image.png

解决方案

不设置version或设置为2

image.png

10001

错误描述

英文:for bad instruction

中文:虚拟机遇到非法的指令

问题原因

check response output

  1. 合约升级失败,可能为合约版本号降低。

  2. 合约名不匹配所导致。

  3. 调用合约时,合约内部存在变量没有初始化或者集合中没有值,但是仍然获取集合中的元素时。

解决方案

  1. 合约编写的版本和编译器版本不一致,导致编译后的文件无法执行。

    合约编写的版本:

    image.png

    使用的编译器的版本:V0.10.2.9

  2. 调用合约时,合约内部存在变量没有初始化或者集合中没有值,但是仍然获取集合中的元素时:

    比如直接调用retrieve函数,但是没有提前调用store函数:1

10201

错误描述

英文:caused by revert instruction

中文:合约内调用了revert指令导致合约异常终止

问题原因

  1. output如果为空,可能是调用合约的方法签名或参数错误。

  2. 合约内部调用require主动抛出异常时,output不为空,一般是自定义的异常抛出。

解决方案

  1. 检查方法签名和参数是否正确。

    image.png

  2. 检查是否是自定义的异常抛出,如果是直接将output中的内容转化为String打印即可。

10622

错误描述

英文:native contract startup failed

中文:本地合约启动失败

问题原因

合约编译器使用的不对

解决方案

不同链版本,要求合约的编译器版本不同,查看使用的链对应的合约版本是否正确,通常链版本和合约编译器版本需要一一对应,具体参见 C++ 合约开发说明

20072

错误码描述

英文:sdk time out

中文:SDK超时

问题原因

  1. 看消息是否因为链处理慢,SDK设置的超时时间(默认1分钟)之后才返回的,如下图所示。

    image.png

    这条消息虽然链那边执行成功了,但是40分钟15秒之后才返回,SDK这一侧肯定就超时了。

  2. 看超时的时间段链是否正常,有没有异常关闭的情况。

  3. 看网络是否有问题。

解决方案

参考错误描述。

30000

错误描述

英文:sdk parameter is invalid

中文:SDK参数无效

问题原因

请求的校验没有通过。

解决方案

对比接口文档,是否字段信息填错。

30018

错误描述

英文:message is reached max queue size

中文:消息请求队列中请求已满

问题原因

说明

SDK中默认队列大小:10000。

  1. 业务量较大,SDK处理不过来,导致消息发送队列满。

  2. 链处理交易较慢,导致发出去的消息没有响应,SDK因为队列中的消息没有收到链的响应,导致一直没有完成消费,所以阻塞在队列中了。

  3. V0.10.2.24.5之前的SDK存在建立多连接的问题,SDK可能会不定时发生重连,一旦发生重连,业务消息会因为连接问题发不出去,导致积压在队列中,新的消息自然无法被接收并发送。

解决方案

第一种和第二种情况,可以通过调整SDK队列大小缓解,直接set对应的参数值即可。

image.png

第三种情况的解决方案需要将SDK版本升级至V0.10.2.24.5。