S2 - jt_sendTransaction：memos内容接近900k时交易无法成功

[zyd82]

目前jt_sendTransaction支持的memos的最大上限为900k，但实际上接近900k时交易基本都无法成功。

比如如下交易，memos部分大概818k：

{
    "jsonrpc": "2.0",
    "method": "jt_sendTransaction",
    "params": [
        {
            "from": "jPdx7mG595P6CowtGYbxRkik9HdWUWtB2J",
            "secret": "shhquPeZm7uQ6Rvjrqn6L2cR6H33u",
            "to": "js3MF5kQkTG6NBVj9HEiw9cFe4ckNvMYGg",
            "value": "10",
            "memos": ["jUThScTqwXV3ec2wbUPor9ejgWgP ... ..."] <== 大概818k
        }
}

发送该交易后经常返回t如下的terTIMEOUT；或者返回一个交易哈希，但是又无法查询到该交易哈希的信息。

{
    "error": {
        "count": 1,
        "description": "The compound error.",
        "information": "1 errors"
    },
    "id": 1,
    "jsonrpc": "2.0",
    "result": [
        {
            "error": {
                "description": "No replies received and timeout.",
                "information": "No replies received and timeout."
            },
            "status": -88,
            "type": "terTIMEOUT"
        }
    ],
    "status": 1000,
    "type": "tedCOMPOUND"
}

目前徐欧那边测下来500k基本都是没有问题的，可能接近900k时某个地方有问题，请看一下。

[caivega]

已改成900K, 即921600字节，之前大约897K

[caivega]

我在本地测试，897K可以正常提交(现在是900K），也验证已经上链，如果测试环境不行，需要去日志里边确认一下，这个交易有没有提交到节点，如果没有提交到节点，需要排查中间所有的环节支不支持提交这么多数据上去（有的客户端不支持，或者说默认不支持，很大的数据post提交)

已经修复，下一个build验证

[caivega]

附件是897K的，需要用0x开头的，才是十六进制的，如果不用0x开头，会当成普通的字符串，这样的话字节数就是*2

sample.txt

[zyd82]

测试版本：v0.5.3-dev-20210111-04c8f9a27b4f9ae2e0f7a74c592a900f7d5d8575

目前大概864KB的memos，如果用了0x开头，交易能成功，并且交易哈希能查询到数据。如果没有加0x的话，就会返回如下交易哈希，但是这个交易哈希查不到结果，这个交易时间点大概是今天15：40左右。

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": [
        {
            "result": "C768C10B448F8AECBE4EE5241C9BBFC24D4F8FB8614DA0DBB022A1CBF5CFF3A8"
        }
    ]
}

如果不用0x开头就字节数*2的话，返回的应该是类似如下的信息，而不是返回上面的交易哈希，请考虑是否是这种情况。

{
    "error": {
        "count": 1,
        "description": "The compound error.",
        "information": "1 errors"
    },
    "id": 1,
    "jsonrpc": "2.0",
    "result": [
        {
            "error": {
                "description": "The transaction is ill-formed.",
                "information": "Unsupported Variable Length encoding: 1728212",
                "message": {
                    "from": "jPdx7mG595P6CowtGYbxRkik9HdWUWtB2J",
                    "memos": [
                        "706d2de93 ... ...

[caivega]

没加0x开头的，应该是超过memo最大可放的，应该要返回一个错误的，我看看，为啥没有返回错误，估计是这个bug, 没返回错误

[caivega]

这个交易，C768C10B448F8AECBE4EE5241C9BBFC24D4F8FB8614DA0DBB022A1CBF5CFF3A8， 排查下来是，交易大小验证通过，但是打进区块的时候，因为这个交易太大，导致交易打包出错，现在设置了两个参数，一个是为区块打包用，一个是交易memo用（依然是900K), 同时把memo的大小验证，及交易的大小验证前置，会更快的给出错误，而不是到后期打包进区块的时候才报错

已提交更新，下一个build验证

[zyd82]

测试版本：v0.5.3-dev-20210113-5aa567d27f68102434021e72cbd0bad2349ae99e

在目前的版本上，大概818KB的memos，开头不加0x，交易成功并返回如下哈希（交易时间点是今天大概14：45），但是这个交易哈希仍然查不到结果，看起来问题并没有解决，请再看一下，多谢。

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": [
        {
            "result": "F39C554FB093C16921346E5848DA71C4E48027D298A0B72C3CBA01276CE2FC57"
        }
    ]
}

[caivega]

@zyd82, 把你的memo放到一个文本文件里边，放到附件上，我来试下，我刚才用897K的，没有加0x开头，返回如下"too large memo"的错误

{"error":{"count":1,"description":"The compound error.","information":"1 errors"},"id":1,"jsonrpc":"2.0","result":[{"error":{"description":"Invalid.","information":"too large memo","message":{"from":"root","memos":["8119740c0350cb0ff82ac011fe7a10f06a762df197efcc5b96dbb5f3834bba27afbe594e47e475a85edd875f69e8f37e4410ed4ea9d628d28b666df49b6d68fa0db5fe5e01c34ef4106ee0240e48808d4b7b4

我把我的测试脚本放到附件里边，你可以试试看，我用的是curl命令发送的

sendLargeMemo.zip

[zyd82]

@caivega , 附件是我用的818KB的memo，你试下。 818k.txt

[caivega]

奇怪了，还真有问题。。。我调试下

原因找到了，本地测试环境，完全没问题，因为本地的网络通讯速度很快，测试环境因为带宽只有1M，所以，有这个大memo的区块，在共识中竞争区块的时候，总是lose, 导致大的memo一直进不了区块。。。

我想想，怎么修复这个问题，不影响整个共识，毕竟共识算法这样做还是比较合理的，只是大的memo一起进不了区块，这个是有问题

[caivega]

根据当前1Mbps, 现在设置memo最大为256K，后续再化化并自动计算这个参数

[zyd82]

v0.5.3-dev-20210115-c552afbe3e28b9fbc03a884397d38562e4a77721版本上验证通过，大约256K的memo，加或不加0x，交易都成功。