Add backoff procedure to the proof courier receive procedure #637
Conversation
ffranr
force-pushed
the
recev-backoff
branch
2 times, most recently
from
c2bac16 to
74716ff
Compare
|
I've updated this PR and the new itest is now passing. This PR does not add the backoff procedure to the hashmail proof courier receive process. This PR does not add an itest to ensure that the asset is eventually correctly received by the receiving node when the universe proof courier is used. Such a test does exist for the hashmail proof courier (see |
ffranr
force-pushed
the
recev-backoff
branch
2 times, most recently
from
aaa4ea5 to
abbb6ce
Compare
|
I've made a few changes to this PR today. I've added a new RPC endpoint for subscribing to asset receive event notifications specifically. |
ffranr
force-pushed
the
recev-backoff
branch
2 times, most recently
from
861f483 to
d6978b3
Compare
This commit also renames the proof transfer event struct to support both delivery and receiving type proof transfers.
There was a problem hiding this comment.
Looks great! Happy to have all these new reliability features in.
One bit I'm confused about is teh new ntfn channel in the custodian - I don't see additional code for actually broadcasting events on that channel, is it rebroadcasting backoff events from somewhere? I see it in the new itest but am missing how its wired up.
@jharveyb The custodian executes And then the courier's backoff handler broadcasts events via the In other words, all we had to do to hookup the custodian was to register its subscribers with the courier. |
The functionality introduced in this commit allows us to subscribe to events emanating from the courier handle during proof retrieval.
This commit renames a helper function for clarity.
Fixes #512
This PR generalises the proof courier proof transfer backoff procedure so that it can be used for both retrieving and delivering proofs. It also extends the universe proof courier's proof retrieval functionality using the backoff handler.