Merge pull request #3242 from nspcc-dev/improve-subs-doc
Improve notification subsystem documentation
This commit is contained in:
commit
90e18ec743
2 changed files with 9 additions and 1 deletions
|
@ -33,7 +33,7 @@ Filters use conjunctional logic.
|
|||
* new in-block transaction is announced after block processing, but before
|
||||
announcing the block itself
|
||||
* transaction notifications are only announced for successful transactions
|
||||
* all announcements are being done in the same order they happen on the chain
|
||||
* all announcements are being done in the same order they happen on the chain.
|
||||
First, OnPersist script execution is announced followed by notifications generated
|
||||
during the script execution. After that transaction execution is announced. It is
|
||||
then followed by notifications generated during this execution. Next, follows the
|
||||
|
@ -41,6 +41,10 @@ Filters use conjunctional logic.
|
|||
they're in the block. After all in-block transactions announcements PostPersist
|
||||
script execution is announced followed by notifications generated during the
|
||||
script execution. Finally, block announcement is followed.
|
||||
* notary request events announcements are not bound to the chain processing.
|
||||
Trigger for notary request notifications is notary request mempool content
|
||||
change, thus, notary request event is announced every time notary request
|
||||
enters or leaves notary pool.
|
||||
* unsubscription may not cancel pending, but not yet sent events
|
||||
|
||||
## Subscription management
|
||||
|
|
|
@ -43,6 +43,10 @@ import (
|
|||
// unblocking in this mode. No unsubscription is performed in this case, so it's
|
||||
// still the user responsibility to unsubscribe.
|
||||
//
|
||||
// All Receive* methods provide notifications ordering and persistence guarantees.
|
||||
// See https://github.com/nspcc-dev/neo-go/blob/master/docs/notifications.md#ordering-and-persistence-guarantees
|
||||
// for more details on this topic.
|
||||
//
|
||||
// Any received subscription items (blocks/transactions/nofitications) are passed
|
||||
// via pointers for efficiency, but the actual structures MUST NOT be changed, as
|
||||
// it may affect the functionality of other notification receivers. If multiple
|
||||
|
|
Loading…
Reference in a new issue