You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the issues that #3047 surfaced relates to the resiliency of AtlasDB "attachments" events. These events are pushed from the chains-coordinator thread over a synchronous channel to the p2p thread, which inserts the attachments into the AtlasDB, and includes any newly-fulfilled attachments in the network result struct. This is pushed to the relayer thread, which notifies the event-listener.
When the node shuts down, these events can be lost. Instead, the coordinator thread should be emitting these events in a more resilient way (by writing them to the AtlasDB themselves).
The text was updated successfully, but these errors were encountered:
The atlas DB writes have to happen in the same (logical) transaction as the transaction that writes out both the Stacks block to the chainstate and the events to the event observer.
At the same time, we need to determine the newly-arrived hashes, which get fed to the event observer, in the same transaction that feeds the block receipts to the event observer.
One of the issues that #3047 surfaced relates to the resiliency of AtlasDB "attachments" events. These events are pushed from the
chains-coordinator
thread over a synchronous channel to thep2p
thread, which inserts the attachments into the AtlasDB, and includes any newly-fulfilled attachments in the network result struct. This is pushed to therelayer
thread, which notifies the event-listener.When the node shuts down, these events can be lost. Instead, the coordinator thread should be emitting these events in a more resilient way (by writing them to the AtlasDB themselves).
The text was updated successfully, but these errors were encountered: