Always return "Target transaction accepted" error if the target transation was
either accepted by the moment of command run or during the command
handling. Exit with code 1 in both cases. Adjust TestAwaitUtilCancelTx
correspondingly, allow both cases in test. Simplify the test along the
way, remove useless code.
Close#3365.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Close#3366. Roll back the test structure to the one that it has before
d2a7162217. Add one extra block to ensure
that main transaction won't be finilized. Add NVB increment slippage to
avoid race between the first fallback acceptance and block acceptance.
Add NVB increment slippage to the rest of fallbacks for test structure
unification.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Add error channel to prevent data race in the test.
Increase waiting interval for subscriptions awaiting up to 2 seconds.
Failing is caused by slow subscriptions.
Close#2958
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
To prevent `Expired transaction (-510) - transaction has expired:
ValidUntilBlock = 8, current height = 8` VUB have been increased.
Close#3343
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
Occasionally the block is being accepted right after main transaction
submission. Added two branches into this TestAwaitUtilCancelTx. One
branch handles the case of original transaction acceptance, the
other branch handles the conflicting transaction acceptance.
Close#3365
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
Default http.Client and http.Transport can be really slow. Also on
windows Timeout: time.Second was not enough. Probably network related
issue. As mentioned in https://github
.com/nspcc-dev/neo-go/issues/2975#issuecomment-1750523651 forcely use
only tcp4 and FallbackDelay: -1. This made TestRPC little bit faster so
gh windows runner can manage it without timeout or POST request fails.
Close#2975Close#3314
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
FaultException can be non-empty even in Halt state when there were
problems with stack marshaling to JSON.
Signed-off-by: Evgenii Stratonikov <fyfyrchik@runbox.com>
This is not the way intended in https://github.com/neo-project/proposals/pull/156.
-511 covers _both_ cases because users hardly can distinguish one from another,
it's just that our mempool implementation has error codes for both..
Signed-off-by: Roman Khimov <roman@nspcc.ru>
mempool.ErrInsufficientFunds is used when sender doesn't have enough
balance to pay the submitted transaction fees (-511 code according to
https://github.com/neo-project/proposals/pull/156). mempool.ErrConflict is
used when sender is not able to pay the overall transactions fee sum in
the pool (generic -500 error according to the proposal).
This bugfix is kind of breaking change for those users who relied on the
old -511 code previously returning "insufficient funds" error.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
If we're withdrawing funds to contract that has onNEP17Payment method,
then it may call Notary's withdraw one more time, but the account's
state is not yet updated by this moment.
The problem is similar to https://github.com/neo-project/neo/pull/2734.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
