Skip to content

fix(api): stamp the new chain ID on flushed transactions - #1059

Merged
rickyrombo merged 1 commit into
mainfrom
fix/new-chain-flush-chain-id
Oct 23, 2026
Merged

rickyrombo merged 1 commit into
mainfrom
fix/new-chain-flush-chain-id

Conversation

@rickyrombo

Copy link
Copy Markdown
Contributor

Pairs with OpenAudio/go-openaudio#601. Merge after it, and deploy before the new-chain flusher is turned on.

Problem

go-openaudio#601 has core refuse a ForwardTransaction whose chain ID differs from its own. On audius-mainnet-beta it also refuses one that names no chain at all. That stops the old chain's gossip from leaking into the new chain's mempool. The flusher forwards through the same RPC and stamps nothing, so once #601 is out the new chain refuses every queued row and the flusher stalls on the first one.

Change

  • New NewChainID config field. It defaults to audius-mainnet-beta in prod and openaudio-devnet in dev, and newChainId overrides it. Stage has no default, because it has no new chain.
  • flushRow stamps it on every ForwardTransactionRequest.
  • With newChainFlushEnabled set but no chain ID, the server logs an error and does not start the flusher, rather than starting one the new chain will refuse.

The chain ID is configured rather than read back from newChainUrl on purpose. Stamping whatever the target reports would always pass the check. A configured value means that if newChainUrl points at a node on another chain, the flusher stalls on the first refused row instead of writing the backlog there.

Dependency

Bumps github.com/OpenAudio/go-openaudio to #601's head (8388df0b) for the new chain_id field. After #601 merges, re-pin to the merge commit on main. The bump spans several releases. The full suite builds and passes except as noted below.

Tests

  • TestNewChainFlusherSends asserts that every forward carries the configured chain ID.
  • go test ./... with the compose db and Elasticsearch services up: everything passes except TestFeedScheduledReleases, which fails the same way on main without this change.

🤖 Generated with Claude Code

go-openaudio#601 makes core refuse a ForwardTransaction whose chain ID
differs from its own, and on audius-mainnet-beta also one with no chain ID
at all. That closes the leak of the old chain's gossip into the new
chain's mempool, but the flusher forwards the same way and stamps nothing,
so after #601 the new chain would refuse every queued row.

The flusher now stamps NewChainID on each forward. It defaults to
audius-mainnet-beta in prod and openaudio-devnet in dev, and newChainId
overrides it. It is configured rather than read back from newChainUrl so
the check still means something: pointed at a node on another chain, the
flusher stalls on the first refused row instead of writing the backlog
there. With flushing enabled and no chain ID, the flusher logs and does
not start.

Bumps go-openaudio to #601's head for the chain_id field.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@rickyrombo
rickyrombo merged commit aadba5b into main Oct 23, 2026
2 checks passed
@rickyrombo
rickyrombo deleted the fix/new-chain-flush-chain-id branch October 23, 2026 07:30
rickyrombo added a commit that referenced this pull request Oct 23, 2026
Follow-up to #1059, which pinned `github.com/OpenAudio/go-openaudio` to
OpenAudio/go-openaudio#601's branch head (`8388df0b`) to get
`ForwardTransactionRequest.chain_id` before #601 merged. #601 is on
`main` now, so this pins to `main` (`9dce6d97`) instead of a commit that
never landed there.

Only `go.mod` and `go.sum` change. Besides #601, the bump picks up
go-openaudio#595, which touches only the genesis writer, nothing the API
imports.

## Tests

`go build ./...` passes. With the compose `db` up, the new-chain flusher
tests (including the chain-ID stamping assertion) and `./config` pass.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5.5 <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