Revert "chore(deps): bump go-openaudio ETL to halt-on-block-error (#883)"

[raymondjacobson]

Summary

Reverts #883, pinning go-openaudio back to v1.3.1-0.20260529221831-4d1c9dfdfb52.

The halt-on-error behavior from upstream go-openaudio#323 is correct in isolation, but is incompatible with the current dual-run state: Python and api-side ETL both write to overlapping tables, and the on-chain plays bridge from #881 doesn't ON CONFLICT-protect against rows Python has already written. So:

• Pre-chore(deps): bump go-openaudio ETL to halt-on-block-error (#323) #883: the failure was silently swallowed by continue — ETL was effectively a no-op on essentially every block since feat(indexer): bridge on-chain plays into the plays table #881 deployed, but block_diff stayed green because Python's writes kept MAX(blocks.height) moving. Block-level data loss masked by Python carrying the load.
• Post-chore(deps): bump go-openaudio ETL to halt-on-block-error (#323) #883: the same failure crashes the indexing loop. We saw it tonight at processBlock failed on block 25415514, reproducibly across pod restarts because Python writes the same plays in the same block before the ETL gets to it. Once fix(indexer): errgroup.WithContext so ETL halt actually exits the process #884 (the api-wrapper fix that makes that halt actually exit the process) ships, every pod would crashloop the moment it tries to index any recent block.

So shipping #883 + #884 without first handling the cross-writer collision points would convert today's silent wedge into a continuous outage that takes the parity jobs (IndexChallengesJob, UserListeningHistory, HourlyPlayCounts, etc.) down with the ETL. Strictly worse.

Plan

1. This PR: pin upstream back to the pre-halt version. Today's silent wedge stays in place — bad, but bounded — and the parity jobs keep ticking.
2. Close fix(indexer): errgroup.WithContext so ETL halt actually exits the process #884 (already done). The diagnosis there is correct, but it amplifies chore(deps): bump go-openaudio ETL to halt-on-block-error (#323) #883's bad sequencing, so we re-land it after chore(deps): bump go-openaudio ETL to halt-on-block-error (#323) #883 is safe to re-ship.
3. Revert fix(etl): halt on block indexing failure OpenAudio/go-openaudio#323 upstream too, so no future bump trips this accidentally.
4. Audit + fix the cross-writer collision points in pkg/etl — start with the plays bridge (feat(indexer): bridge on-chain plays into the plays table #881), apply the same ON CONFLICT pattern Don't use "latest" for arch dependent builds for simplicity #319 used for the blocks table. Then sweep anywhere else ETL and Python touch the same row.
5. Re-land go-openaudio#323, then api#883, then api#884 (in that order). At that point the halt-on-error guarantee is honest.

Bump details (revert direction)

	from	to
github.com/OpenAudio/go-openaudio	v1.3.1-0.20260529230137-819100b28c94	v1.3.1-0.20260529221831-4d1c9dfdfb52
github.com/OpenAudio/go-openaudio/pkg/etl	v1.3.1-0.20260529230137-819100b28c94	v1.3.1-0.20260529221831-4d1c9dfdfb52

Test plan

• go build ./... clean.
• After deploy: confirm new pod boots, no processBlock failed halt log on block 25415514 (it'll go back to silent continue).
• Verify parity jobs still tick and block_diff stays at 0 (no functional change vs. pre-chore(deps): bump go-openaudio ETL to halt-on-block-error (#323) #883 prod).

🤖 Generated with Claude Code