Skip to content

feat(messaging): expose pending (gathered-but-unpooled) messages via handle#575

Draft
kariy wants to merge 3 commits into
mainfrom
feat/pending-messages
Draft

feat(messaging): expose pending (gathered-but-unpooled) messages via handle#575
kariy wants to merge 3 commits into
mainfrom
feat/pending-messages

Conversation

@kariy
Copy link
Copy Markdown
Member

@kariy kariy commented May 26, 2026

Adds a way to observe messages that have been picked up from the settlement layer but not yet placed into the transaction pool — the in-flight window the service previously held only as a transient local variable, with no way to query it.

The buffer is in-memory and volatile rather than DB-backed because this state is genuinely transient: a message is "pending" only between being gathered and being accepted by the pool, and the existing L1→L2 index already records the durable post-insert outcome. Persisting it would conflate in-flight state with history. It is created fresh on each start() and discarded on shutdown, so a query reflects only the currently running drain loop, never the past.

Entries are keyed by their (block, tx_index) position to keep the retry path correct: when a pool insert fails the batch breaks and the unprocessed tail is re-gathered on the next tick, and keying by position means those re-gathered messages overwrite their prior entry instead of duplicating. A message enters the buffer the moment its batch is gathered (it has been "picked up") and leaves the instant the pool accepts it, which is exactly the window in question.

The buffer is guarded by a std::sync::Mutex rather than an async lock because it is only ever held for brief synchronous insert/remove/snapshot operations, never across an .await. It is surfaced through MessagingServiceHandle::pending_messages() as a snapshot ordered by position; an RPC endpoint is deliberately left out of this change so the core primitive can land first.

Track messages gathered from the settlement chain but not yet accepted by
the tx pool in a volatile in-memory buffer, queryable through
MessagingServiceHandle::pending_messages().

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@kariy kariy force-pushed the feat/pending-messages branch from 56de2f4 to 416a0d6 Compare May 26, 2026 04:39
kariy and others added 2 commits May 25, 2026 23:42
Drop a redundant clone on a Copy `Address`, factor a complex test-helper
return type into a `StreamHarness` alias, and inline `format!` args.
These targets aren't linted by the `-p katana` CI clippy, so they had
accumulated unnoticed.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Extract the per-batch gather/insert/commit logic from the spawned task in
`start()` into a `process_batch` async fn (behavior-preserving), so the
buffer wiring is unit-testable without a real settlement chain. Add tests
for the three paths the buffer cares about: pool accepts all (pending
clears), pool rejects (messages stay pending), and partial failure (only
the un-pooled tail stays pending).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant