About exitcode=133，Why?

[qzmer1104]

The last transaction triggered Exit-code 133, but it has been several hours since the second transaction. Why is the seqno obtained still the old one?

This is the newly added log

WalletV5 walletV5 ……
Long seqno = walletV5.getSeqno()
 log.info("Send-Jetton {}, seq: {}", walletV5.getAddress().toString(true, true, false), seqno);

{"@type":"error","code":500,"message":"LITE_SERVER_UNKNOWN: cannot apply external message to current state : External message was not accepted\nCannot run message on account: inbound external message rejected by transaction A93C7DEC4A8F450263D8BA896C322BB4FC411D50771F9A5C5D6693AF2D19F9DC:\nexitcode=133, steps=49, gas_used=0\nVM Log (truncated):\n...SIGNU\nexecute PUSHCONT x28945F0ADB31E1F2C087\nexecute IFNOT\nexecute XCHG s2\nexecute NOT\nexecute XCHG2 s0,s7\nexecute AND\nexecute THROWIF 132\nexecute XCPU s2,s5\nexecute EQUAL\nexecute THROWIFNOT 133\ndefault exception handler, terminating vm with exit code 133\n","@extra":"53442a10-be76-4f42-9805-cb9bcf517773"}

[qzmer1104]

I have stored the seqno of the last transaction locally, and I get the latest one each time through wallet.getSeqno(). If it is found to be less than or equal to the cached seqno, it will automatically increase by 1 to avoid Error 133. However, my seqno is already far greater than the actual one, so why is it still reporting Error 133?

[qzmer1104]

@neodix42 Has there been no maintenance recently?

[qzmer1104]

I found that after restarting Application, tonlib still needs to synchronize nodes. Tonlib needs to reconstruct each time it broadcasts a transaction instead of caching it, right?

[neodix42]

Hi, you can try using .ignoreCache(false) so the state of the blockchain would be cached.
Also with the next release, tonlib will have a method to update init block within the config, which will speed up the subsequent sync process big times.

[qzmer1104]

Hi, you can try using .ignoreCache(false) so the state of the blockchain would be cached. Also with the next release, tonlib will have a method to update init block within the config, which will speed up the subsequent sync process big times.

Is it best practice for Tonlib to use singleton pattern or spring's singleton bean?

1. Because the above error will not occur when using multiple instances
2. However, multiple instances can easily cause data to be resynchronized after each instance is constructed.

I will use .ignoreCache first to see the effect

[qzmer1104]

Hi, you can try using .ignoreCache(false) so the state of the blockchain would be cached. Also with the next release, tonlib will have a method to update init block within the config, which will speed up the subsequent sync process big times.

Is it best practice for Tonlib to use singleton pattern or spring's singleton bean?

1. Because the above error will not occur when using multiple instances
2. However, multiple instances can easily cause data to be resynchronized after each instance is constructed.

I will use .ignoreCache first to see the effect

I found that my application used .ignoreCache(false) at the beginning。

So I think this configuration cannot avoid the problem of resynchronizing nodes caused by restarting and reconstruct Tonlib every time