Skip to content

[API-331] Index pubkeys from core transactions - #433

Merged
schottra merged 4 commits into
mainfrom
index-pubkeys
Oct 1, 2025
Merged

[API-331] Index pubkeys from core transactions#433
schottra merged 4 commits into
mainfrom
index-pubkeys

Conversation

@schottra

@schottra schottra commented Sep 30, 2025

Copy link
Copy Markdown
Contributor

Cleans up the original test indexer and uses modern audiusd patterns (thanks @alecsavvy !) to index core blocks. At the moment, we're just handling user create transactions and deriving/setting the pubkeys for users so that comms works immediately.

We're leveraging the existing indexing_checkpoints table to keep track of the last block we saw. This should obviously be more robust when we implement full indexing, but it mirrors how we currently do pubkey backfills in the legacy codebase.

I might advise looking at indexer.go and index_user.go as raw files, since the diff is illegible 😅

TODO: write some tests for this before merging.

@raymondjacobson raymondjacobson left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm! except for acdc part

Comment thread config/config.go Outdated
Comment thread indexer/indexer.go

@rickyrombo rickyrombo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

almost wonder if both solana-indexer and indexer could live together on the same pod

Comment thread indexer/index_user.go Outdated
Comment thread indexer/index_user.go
// todo: better validation
return nil
func (ci *CoreIndexer) createUser(dbTx pgx.Tx, logger *zap.Logger, em *corev1.ManageEntityLegacy) error {
_, pubkey, err := server.RecoverPubkeyFromCoreTx(&core_config.Config{

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

really interesting to pull this in from the server package of audiusd

@schottra
schottra merged commit d498bb9 into main Oct 1, 2025
5 checks passed
@schottra
schottra deleted the index-pubkeys branch October 1, 2025 15:15
rickyrombo added a commit that referenced this pull request Aug 5, 2026
Moves off the 2026-07-27 pseudo-version onto the real tag. Three changes come
with it, all pkg/etl-only, so the root module pin is untouched:

  * album saves and reposts record save_type/repost_type 'playlist' rather
    than deriving 'album' from the mutable playlists.is_album at index time
    (OpenAudio/go-openaudio#428). The rows already written as 'album' are
    backfilled by ddl 0236 in this PR.
  * one current row per user is enforced via users_current_uniq_idx, and the
    fifteen DISTINCT ON dedupe subqueries in genesis-writer collapse to plain
    joins (#425). The duplicates that index cannot coexist with are removed by
    ddl 0237 in this PR, which runs first.
  * that index migration no longer deletes anything itself (#433), so no ETL
    migration modifies row data.

Also rewrites the comment above the ETL config. It described the migrations
as additive without saying why that matters; it now records the line being
held — a module bump reaches this database automatically, so data repair
belongs in ddl/ where it goes through review and the pre-roll migrate Job —
and the corollary that 0035 fails if ddl 0237 has not run, which the Job's
ordering is what prevents.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rickyrombo added a commit that referenced this pull request Aug 5, 2026
Supersedes #1008, #1009 and #1010, which were the same work split three
ways.

## Why one PR

These three changes are only correct **together, in one deploy**. Split,
each one alone breaks something:

| merged alone | result |
|---|---|
| the bump | ETL `0035` creates `users_current_uniq_idx`, **fails on the
existing duplicates**, `RunMigrations` errors and the indexer won't
start |
| `0236` (album) | the old indexer keeps deriving `album` from
`is_album` and undoes the backfill |
| `0237` (users) | harmless, but pointless without the index that stops
it recurring |

As one PR the deploy is atomic, and the ordering inside it is guaranteed
by existing machinery: `bridge migrate` runs as a pre-roll Job that
every serving Deployment `DependsOn` (serving pods get
`runMigrations=false`), so both ddl migrations complete before the
indexer starts and runs the ETL's.

## Contents

**`0237_users_one_current_row_backfill`** — deletes 5 duplicate
`is_current` rows from `users`. Small count, large blast radius: joins
from an entity to its owner's wallet fan out, measured at **+18 tracks
and +787 follows** on a production clone. Must precede the ETL index.

**`0236_saves_reposts_album_to_playlist`** — 670 saves and 528 reposts
written as `album` collapse to `playlist`. `on_save`/`on_repost` are
disabled for the update (their notification `group_id` embeds the type,
so a plain UPDATE would mint duplicate favourite notifications);
`trg_saves`/`trg_reposts` stay enabled so the search indexer sees the
change.

**`deps: pin pkg/etl v1.6.4`** — brings OpenAudio/go-openaudio#428
(album type), #425 (the `users` invariant + genesis-writer join
simplification) and #433 (`0035` no longer deletes anything).

## The delete moved out of the ETL migration

`v1.6.3`'s `0035` deleted the duplicates itself. Since ETL migrations
run automatically at indexer start, that made a `go get` able to remove
rows from this database. #433 split it: the index stays in the ETL
migration, the repair moved to `0237` here. **`v1.6.4` ships zero
`DELETE` statements** — verified against the resolved module, not just
the tag.

The comment above the ETL config now records that line, and its
corollary: an ETL migration can depend on a ddl one having run, and
`0035` fails loudly if `0237` hasn't.

## Verified

- Resolved module `pkg/etl@v1.6.4` contains `0035` with `CREATE UNIQUE
INDEX` and **0** `DELETE` statements.
- Both migration orders against fixtures: backfill→index applies cleanly
(`violations 0`, `indisvalid = t`); index→backfill fails with `could not
create unique index … Key (user_id)=(98311147) is duplicated`, which is
the intended signal that `0237` hasn't run.
- Both migrations idempotent; re-running is a no-op.
- `0236` fires **zero** `on_save`/`on_repost` triggers against a fixture
with the real wiring, and exactly one `pg_notify` per updated row.
- `go build ./...` and `go vet ./indexer/` clean.
- No FK references `users`; its triggers are INSERT / INSERT OR UPDATE,
so the delete fires neither.
- Cutting `pkg/etl/v1.6.4` did not move `openaudio/go-openaudio:stable`
— still the 2026-07-30 `v1.8.2` digest, so no node-operator rollout.

## Not established

The cause of the duplicate `users` rows. Both indexer create paths
reject an existing user, so a single writer can't produce them; a second
writer can, since check-then-act isn't atomic across transactions. Three
of five pairs put a bare-hex `txhash` next to a `0x`-prefixed one, which
fits but doesn't prove it. The index will surface it if it recurs.

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

---------

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

3 participants