Waku Topic Subscriptions and Cache Consistency

Direct Answer

Waku topic subscriptions provide best-effort, eventually consistent pub/sub delivery over libp2p content topics. They do not guarantee total ordering, exactly-once delivery, or strong cache coherence across peers. Subscribing or unsubscribing controls future message reception only; it does not evict or refresh previously cached messages. Waku does not specify a universal API operation to verify message freshness against delivery semantics; recency is typically inferred from payload timestamps, sequence numbers, or store/replay queries where available.

Confirmed Facts

• Delivery semantics depend on the Waku node implementation and protocol, such as Filter, Store, or Light Push.
• Network partitions can delay or drop messages, so local caches may show stale content relative to remote topic state.
• Topic unsubscribe stops future messages but does not invalidate cached messages.
• No standard Waku API is documented as a universal freshness check against configured delivery semantics.

Likely Explanation

Perceived staleness after a partition is expected because subscriptions distribute messages without synchronizing application caches. Cache eviction is an application responsibility, not a side effect of topic lifecycle events.

Steps for This Case

1. Identify the Waku node implementation and version in use, for example nwaku, waku-go, or waku-js.
2. Confirm which protocol carries the topic subscription: Filter, Store, or Light Push.
3. Add application-level freshness metadata, such as a payload timestamp or sequence number, to each message.
4. Before updating the cache, compare the incoming message timestamp or sequence against the cached value.
5. After a partition heals, reconcile missing messages through store or replay queries where available instead of assuming the cache is current.

Verification

Run a controlled partition test: publish while a peer is disconnected, reconnect, then compare cached messages against timestamps or store query results. This confirms whether stale entries survive reconnection for your specific build.

Missing Diagnostic Detail

Which Waku node implementation and version are you running, and which protocol handles the topic? This determines whether store-based replay or timestamp verification is available.

Assumptions and Uncertainty

Behavior differs between Waku versions and node implementations. The guidance above is based on general protocol knowledge, not version-specific documentation, so confirm guarantees against the release notes for your exact build before relying on them in production.