Context
SubscribeReceiveEvents / SubscribeSendEvents / SubscribeMintEvents cover the transfer + mint lifecycle well, but several high-level state changes that downstream consumers care about still have no event and can only be detected by polling. Surfaced while bringing up the tap-sdk regtest harness — every WaitFor* helper ends up as a require.Eventually loop because there is no edge-triggered notification it could subscribe to.
Filing as one ticket so the event surface can be designed coherently.
Missing events
- Asset visibility event. No signal when a new asset first becomes visible to
ListAssets (post-universe sync, post-bootstrap from a federation peer, post-receive flow finalizing). Consumers have to poll ListAssets until the expected asset appears.
- Group discovery event. Same pattern for
ListGroups. After bootstrapping a federation peer, consumers poll until the group shows up.
- Universe sync completion event.
SyncUniverse is synchronous but the bootstrap→address-creation flow has races that need a "sync finished" signal per peer. An event for UniverseSyncCompleted / UniverseSyncFailed with the peer host and the sync target would replace the retry loops consumers currently wrap around NewAddr.
- Federation membership change event. After
AddFederationServer, the peer is added but not immediately syncable. An event fired when the peer transitions to "syncable" (or when gossip metadata lands) would remove another polling pattern.
- Chain-synced event.
GetInfo exposes synced_to_chain. Consumers that want to gate work on chain-sync today poll that field. An edge-triggered event at the rising edge would let them subscribe once.
- Mint event replay / starting cursor.
SubscribeMintEvents only emits transitions from connect time forward. A subscribe option that first replays the current state (or the last transition per batch key) would close the race where a batch finalizes between FinalizeBatch and Subscribe, which currently forces consumers to fall back to polling ListBatches.
Design doc:
TAPD_EVENT_SUBSCRIPTIONS_DESIGN.md
Context
SubscribeReceiveEvents/SubscribeSendEvents/SubscribeMintEventscover the transfer + mint lifecycle well, but several high-level state changes that downstream consumers care about still have no event and can only be detected by polling. Surfaced while bringing up the tap-sdk regtest harness — everyWaitFor*helper ends up as arequire.Eventuallyloop because there is no edge-triggered notification it could subscribe to.Filing as one ticket so the event surface can be designed coherently.
Missing events
ListAssets(post-universe sync, post-bootstrap from a federation peer, post-receive flow finalizing). Consumers have to pollListAssetsuntil the expected asset appears.ListGroups. After bootstrapping a federation peer, consumers poll until the group shows up.SyncUniverseis synchronous but the bootstrap→address-creation flow has races that need a "sync finished" signal per peer. An event forUniverseSyncCompleted/UniverseSyncFailedwith the peer host and the sync target would replace the retry loops consumers currently wrap aroundNewAddr.AddFederationServer, the peer is added but not immediately syncable. An event fired when the peer transitions to "syncable" (or when gossip metadata lands) would remove another polling pattern.GetInfoexposessynced_to_chain. Consumers that want to gate work on chain-sync today poll that field. An edge-triggered event at the rising edge would let them subscribe once.SubscribeMintEventsonly emits transitions from connect time forward. A subscribe option that first replays the current state (or the last transition per batch key) would close the race where a batch finalizes betweenFinalizeBatchandSubscribe, which currently forces consumers to fall back to pollingListBatches.Design doc:
TAPD_EVENT_SUBSCRIPTIONS_DESIGN.md