Some clients need more flexible awaiting options (e.g. for short-blocks
networks). The default behaviour is not changed, all exported APIs are
compatible. Ref. https://github.com/nspcc-dev/neofs-node/issues/2864.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
pollTime is never 0 since MillisecondsPerBlock protocol configuration value
is present in `getversion` RPC response since 0.97.3 release. We don't have such
old RPC servers in the network anymore, thus this fallback code may be
safely removed.
Signed-off-by: Anna Shaleva <shaleva.ann@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>
`makeWsRequest` creates a channel for response and waits for it. If between
creating the channel and starting the reading `select` connection is lost
(`writerDone` channel is closed), nothing reads from the channel and a
deadlock appears. Looking at "done" channels when transferring RPC data
solves the issue. Closes#3530.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Every client's (Un)Subscription call does two things: an RPC call and a
subscription map lock (two of maps currently). If we imagine that there is
one routine that tries to subscribe (A) and one routine that tries to
unsubscribe (B), the following sequence can happen:
0. Current number of subscriptions is X
1. B does an RPC and makes number of subscriptions X-1
2. A does an RPC and makes number of subscriptions X again
3. A holds subscription locks and rewrites client's subscription state
(subscription with ID X now points to a different channel; channel that
was registered by B is lost and is not related to any real subscription
but is still included in the `receivers` map)
4. B holds subscription locks and drops subscription X (first, it is an
error and we have just lost a subscription that we think was made
successfully second, we have lost a channel in the `receivers` map, and
no corresponding subscription points to it)
5. X subscription is received by the WS client (in practice it is a new
block, 100ms, quite often to be sure this issue happens every hour), we
range through the receivers, see no corresponding subscription, and
panic.
Closes#3093.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signers are very important for notary checks and keeping/passing an additional
copy of them is very inconvenient. Exposing them from invoker makes them
available in actors too.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Most of the time people are interested in successful executions. Unfortunately,
unwrap package can't help here because of a different result structure (some
interface abstract can help, but it's still mostly stack-oriented and sessions
can be a problem), so this additional interface is needed.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Fix#3130. "Exception" is used for name since it's shorter and that's the name
used in JSON. "VMFault" was also considered as well as "FaultException"
(which mirrors result.Invoke).
Signed-off-by: Roman Khimov <roman@nspcc.ru>
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>
Add waiting for startSending to ensure that the client is ready before
the server starts sending messages.
Close#3005Close#3312
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
Revert 5f6c01336c, remove all multierror
related nolint comments and use multierror wrapping instead.
Close#2906.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
This one doesn't really work now, it's Legacy. Replace with something N3-ish.
Thanks @lock9 for reporting.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Try to subscribe for headers firstly, and then if RPC server doesn't
have this ability, fallback to block subscriptions to manage transaction
awaiting.
Close#3260.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Adjust names of all used structures, no need to duplicate `Waiter` everywhere,
we already in the `waiter` package. Also, adjust comments to Actor so that links
to Waiter are properly described in docs.
Ref. #3265.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
It can be used to work with the results of
CreateCallAndPrefetchIteratorScript() execution. The first item must be
an array and the optional second item must be an iterator, containing
remaining elements.
Signed-off-by: Evgenii Stratonikov <fyfyrchik@runbox.com>
There are use-cases when not only Actor, but also Invoker and even
simple RPC client must wait (e.g. sendtx or dumptx CLI commands). Actor
requires optional signers in constructor, and it's not always
appropriate to create Actor only to be able to use Waiter, sometimes
it's needed to use only Waiter without Actor.
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
Change first argument of NewWaiter to be able to directly accept RPC
Client and export for external usage.
Refs #3244.
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
BlockFilter has PrinaryIndex of int type while block.Block structure
itself has PrimaryIndex of byte. It's needed to prevent changing
filters field type and all associated subscriptions logic on
server side.
Refs #3241.
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
New event is to notify the user about header's content by the moment
when block is stored (which happens after block's processing). This is
needed for proper Waiter work.
Closes#2751.
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
This was recently added in neotest, but working with the real RPC is
still not enjoyable. This commit extends `wallet.Account` with
invocation script builder to aid network fee calculations and signing.
Signed-off-by: Evgenii Stratonikov <fyfyrchik@runbox.com>
Add new filter NotaryRequestFilter, support for filtering
NotaryRequestEvents by mempoolevent.Type
(added or removed).
Closes#2425.
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
StateRootInHeader depends on it, so we better immediately return error
if client is not initialised.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
