Mostly it's about Go 1.22+ syntax with ranging over integers, but it also
prefers ranging over slices where possible (it makes code a little better to
read).
Notice that we have a number of dangerous loops where slices are mutated
during loop execution, many of these can't be converted since we need proper
length evalutation at every iteration.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Linter is updated up to v1.60.1, the following issue is fixed:
```
predeclared variable max has same name as predeclared identifier
```
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
64 connections is too much for slow GA runners, we have to keep all of
them alive to avoid failures in the test, but it's impossible since
runners are too slow to iterate through all of them in time.
Close#3442.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
It's needed to give user a hint about what's wrong with the witness
during `calculatenetworkfee` RPC request processing.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Value calculated by calculatenetworkfee is enough to pass the real
tx verification. However, network fee may be decreased, so calculations
are not quite accurate. Need to investigate, why.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Replace native CryptoLib's verifyWithECDsa `curve` parameter by
`curveHash` parameter which is a enum over supported pairs of named
curves and hash functions.
Even though this change is a compatible extension of the protocol, it
changes the genesis state due to parameter renaming. But we're going to
resync chain in 3.7 release anyway, so it's not a big deal.
Also, we need to check mainnet and testnet compatibility in case if
anyone has ever called verifyWithECDsa with 24 or 25 `curve` value.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Do not wait until wsReader routine gracefully finishes its work before
WS connection close. Instead, firstly close the connection, and after
that wait for proper wsReader exit.
It's a harsh way, but I don't have any other options to try, because
wsReader routine hangs on `ws.ReadMessage()` operation for more than
ReadDeadline (more than 5 seconds) during test cleanup which results in
the test timeout.
Close#3378.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Close#2956. The failure reason is similar to the one described in #3396
for TestNotary: Blockchain's notificationDispatcher is listening to
block events from storeBlock via separate channel. By the moment single
block addition is finished, notification may or may not be properly
handled by notificationDispatcher, especially given the fact that our
runners are slow. As a result, assert.Eventually with 1-second awaiting
period may fail. This issue is solved by adding one more block, because
the second AddBlock finishes only when it sends block addition event to
notificationDispatcher loop, which means that the previous event was
handled.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Made connections in parallel to check the limit and attempt to make one
more connection beyond the limit. Only "default" test case is failing,
because default number of connections is 64 (quite large for slow
runners). The failure reason is:
* given ~1 second for [dealing + request] per connection (time is taken
from the test log)
* by the moment 65-th connection is reached, some connections from the
start of the test have died due to inactivity (this process literally
takes 1 minute)
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
1. Replace isFinished atomic variable with a channel, no functional changes
here, just use more common way as all our services do.
2. Do not check erors from SetReadDeadline and ReadMessage on exit. It
seems to be not quite right because connection is not closed by this
moment, and thus, these error checks are racy.
3. Add read timeout for the message reader. It is needed because some
tests may leave message unread in the end which results in hanging
test cleanup.
4. Add drain loop to message reader in order not to block WS reader on
sending message.
Ref. https://github.com/nspcc-dev/neo-go/pull/3392#issuecomment-2031590403.
It's clear that TestBadSubUnsub is hanging on test cleanup, in
particular, on attempt to wait for wsRead routine to exit. The only
place where wsRead routine may hang is sending to msgCh in case if
receiver is not going to read from this channel:
```
2024-04-02T08:14:51.4957621Z goroutine 14329 [chan receive]:
2024-04-02T08:14:51.4958010Z github.com/nspcc-dev/neo-go/pkg/services/rpcsrv.initCleanServerAndWSClient.func1()
2024-04-02T08:14:51.4958344Z D:/a/neo-go/neo-go/pkg/services/rpcsrv/subscription_test.go:80 +0x71
2024-04-02T08:14:51.4958457Z testing.(*common).Cleanup.func1()
2024-04-02T08:14:51.4958757Z C:/hostedtoolcache/windows/go/1.22.1/x64/src/testing/testing.go:1175 +0x17a
2024-04-02T08:14:51.4958903Z testing.(*common).runCleanup(0xc002cf5860, 0x0)
2024-04-02T08:14:51.4959193Z C:/hostedtoolcache/windows/go/1.22.1/x64/src/testing/testing.go:1353 +0x262
2024-04-02T08:14:51.4959291Z testing.tRunner.func2()
2024-04-02T08:14:51.4959566Z C:/hostedtoolcache/windows/go/1.22.1/x64/src/testing/testing.go:1683 +0x51
2024-04-02T08:14:51.4959695Z testing.tRunner(0xc002cf5860, 0x141687410)
2024-04-02T08:14:51.4959976Z C:/hostedtoolcache/windows/go/1.22.1/x64/src/testing/testing.go:1695 +0x25e
2024-04-02T08:14:51.4960115Z created by testing.(*T).Run in goroutine 1
2024-04-02T08:14:51.4960385Z C:/hostedtoolcache/windows/go/1.22.1/x64/src/testing/testing.go:1742 +0x826
```
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Previously findstorage returns null for the results key if a contract
state is not found. C# returns an empty list.
Close#3370
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
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>
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>
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>
Shouldn't affect things much, yet at the same time we no longer need any
connection after we're done with the request.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
