Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix notary request handling #2715

Merged
merged 3 commits into from
Jan 18, 2024
Merged

Fix notary request handling #2715

merged 3 commits into from
Jan 18, 2024

Commits on Jan 18, 2024

  1. morph/event: make a copy of notary request and main transaction 

    It's not compliant with the WSClient documentation and can lead to the
following scenario:
 * SN sends a container creation request
 * IR node with integrated CN receives it, adds to pool and announces to
   neighbors in a regular Neo P2P way
 * IR logic then receives a notification and executes Prepare
 * it adds a signature and changes the shared notary request
 * a neighbor then requests this notary requests and receives a broken one
   (signature mismatch)
 * so it may end up not receiving this original request at all and thus not
   replying to it ever
 * with enough of such nodes you can't create a container

Signed-off-by: Roman Khimov <roman@nspcc.ru>
    @roman-khimov
    roman-khimov committed Jan 18, 2024
    Configuration menu
    Copy the full SHA
    e1171b3 View commit details
    Browse the repository at this point in the history

  2. morph/event: simplify notaryPreparator() 

    Signed-off-by: Roman Khimov <roman@nspcc.ru>
    @roman-khimov
    roman-khimov committed Jan 18, 2024
    Configuration menu
    Copy the full SHA
    cdc9ab3 View commit details
    Browse the repository at this point in the history

  3. morph/event: rework recursion probe 

    In some cases we may not receive the original (sent by SN) request or receive
it with a huge delay, so we shouldn't be relying on this magic. Instead, we
can prevent recursion by checking the FB signer and then main tx cache is
sufficient to not try handling the transaction again. Even if we do that, it's
not a huge problem, the fallback will be the same and a single main tx will be
constructed anyway.

Notice that while we could be checking for main/fallbacks in the notary pool,
they can legitimatelly be evicted from it as well, so it's not a 100% proof
of handling status, therefore we're not doing it, relying on tx hash cache and
fallback stability.

Signed-off-by: Roman Khimov <roman@nspcc.ru>
    @roman-khimov
    roman-khimov committed Jan 18, 2024
    Configuration menu
    Copy the full SHA
    38a5bb1 View commit details
    Browse the repository at this point in the history