feat(solana-indexer) PR 7.1: wire tx-only decoder run loop

[squadgazzz]

Description

With the account half of the stream gone (#4601), the decoder's run loop is transaction-only. It drains the channel from the ingester and, for each transaction, resolves the settlement and SolFlow instructions and routes them to per-program decoders. Those decoders are stubs for now: turning instruction bytes into typed events needs the settlement program's on-chain layout, which comes in a later PR.

Changes

• Implement Decoder::run: drain the channel until the ingester drops the sender
• Route each resolved settlement or SolFlow instruction to a stubbed per-program decoder

How to test

New unit test.

[claude]

Claude finished @squadgazzz's task in 3m 3s —— View job

---

PR Review: wire decoder run loop, join halves, route instructions

• Read the PR diff and changed files
• Understand surrounding decoder/ingester/watchdog context
• Review for correctness, edge cases, style
• Post inline comments for issues
• Post summary

The plumbing reads cleanly — the run loop, the symmetric buffer-or-complete join, the signature guard, and the settlement/SolFlow routing are all reasonable, and the stubbed decoders match the stated scope. Two things worth a look, posted inline:

1. Join assumes one account update per tx (decoder.rs) — the account subscription filters by owner, so a tx touching multiple program-owned accounts emits multiple updates sharing (slot, signature). They clobber each other in the map, and late-arriving ones re-buffer after the pair completes → future false TxUpdateMissing dead-letters. Latent today since the snapshot is dropped, but the singular-account model is baked in here. Worth confirming the assumption holds.
2. Test coverage gap (tests.rs) — both completion tests send the tx first, so on_tx's account-completion arm (decoder.rs:98) is never exercised. A reverse-order test would cover it.

Nothing blocking; (1) is the one I'd resolve (even if just by confirming) before the account snapshot gets consumed.

[gemini-code-assist]

Code Review

This pull request implements the main run loop for the Decoder struct, which joins transaction and account-update halves using a shared partials map and routes tracked instructions to stubbed per-program decoders. It also adds corresponding unit tests to verify the joining, buffering, and dropping behaviors. A critical issue was identified in the join logic: it assumes a strict 1:1 relationship between transactions and account updates, which does not hold true in Solana and can lead to memory bloat, false-positive dead letters, or lost account updates.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The current join logic assumes a strict 1:1 relationship between a transaction and its account updates, which does not hold true in Solana. A single transaction can modify multiple accounts owned by the tracked programs, resulting in multiple SubscribeUpdateAccount messages for the same (slot, signature).

This leads to two major issues:

1. If Tx arrives first: The first Account update removes the Tx from partials and processes it. Any subsequent Account updates for the same transaction will find no Tx in partials and will be inserted into the map, where they will remain indefinitely until the watchdog cleans them up. This causes unnecessary memory bloat and false-positive dead letters.
2. If Account updates arrive first: Each new Account update will overwrite the previous one in partials (since the _ wildcard branch in on_account removes the existing Account and inserts the new one). When the Tx update finally arrives, it will only be paired with the last Account update, and all previous ones are lost.

Recommendation

Redesign the partials map or the join logic to support one-to-many relationships. For example, you could buffer multiple account updates in a collection (e.g., Vec<Box<SubscribeUpdateAccountInfo>>) under the (slot, signature) key, or avoid removing the Tx half immediately if more account updates are expected.

[claude]

The join assumes one account update per transaction, but the ingester subscribes to accounts by owner (accounts = |program| SubscribeRequestFilterAccounts { owner: vec![program.to_string()], .. } in ingester.rs:372). A single settlement/SolFlow tx that writes to several program-owned accounts (PDAs, vaults, …) will emit multiple SubscribeUpdateAccountInfo messages, all sharing the same (slot, txn_signature). With this map keyed on (slot, signature) holding a single PartialHalf::Account:

• If several account halves arrive before the tx, each on_account call clobbers the previously buffered one (the _ arm removes + re-inserts), so only the last survives.
• Once the pair completes and decode fires, the tx entry is gone. Any further account updates for that same tx re-buffer as fresh Account partials that never complete — so once the watchdog lands they'll be dead-lettered as TxUpdateMissing even though the tx was seen.

This is latent today because decode drops the account snapshot, but the whole join model (and account_snapshot: Option<…> / PartialHalf::Account(Box<…>), both singular) bakes in the one-account assumption. Worth confirming whether a tracked tx can touch >1 program-owned account before the snapshot is actually consumed — if so the value likely needs to be a collection keyed per-account, and "pair complete" needs a definition beyond "first account seen".

[claude]

Both completion tests send the tx first, so only on_account's completion path (the Some(PartialHalf::Tx(tx)) arm) is exercised. The symmetric path in on_tx — Some((_, PartialHalf::Account(_account))) => self.decode(&tx) at decoder.rs:98 — where the account half arrives first and the tx completes the pair, is never hit. Worth adding a reverse-order test (send stream_account then stream_tx, assert partials.is_empty()) to cover it.

[gemini-code-assist]

Code Review

This pull request implements the main loop (run) and routing logic (decode) in the Solana indexer's decoder, which drains the stream of transaction updates and routes relevant instructions to stubbed handlers for settlement and SolFlow programs. Unit tests were also added to verify that the decoder drains transactions until the channel is closed. No critical issues were found, so there is no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.