Skip to content

fix(etl): persist track bpm/musical_key/audio_upload_id#334

Merged
raymondjacobson merged 1 commit into
mainfrom
fix/etl-track-bpm-musical-key-parity
Jun 2, 2026
Merged

fix(etl): persist track bpm/musical_key/audio_upload_id#334
raymondjacobson merged 1 commit into
mainfrom
fix/etl-track-bpm-musical-key-parity

Conversation

@raymondjacobson
Copy link
Copy Markdown
Contributor

Summary

The go-etl entity-manager track create/update handlers never persisted bpm, musical_key, is_custom_bpm, is_custom_musical_key, or audio_upload_id. Tracks indexed by go-etl therefore lost these fields entirely (root cause of "tracks uploaded today are missing key/bpm"). This restores parity with apps' discovery-provider populate_track_record_metadata.

Semantics matched 1:1 to apps/.../tasks/entity_manager/entities/track.py:

  • bpm: present + null → clear; present + nonzero number → set; present + 0/non-numeric, or absent → keep existing.
  • musical_key: present + null → clear; present + valid MusicalKey enum value → set; present + invalid → keep existing. Validated against the flats-only enum ("C# minor" is invalid; "D flat minor" is valid).
  • is_custom_bpm / is_custom_musical_key / audio_upload_id: set when present in metadata, otherwise unchanged.

audio_upload_id is also the key the companion repair_audio_analyses backfill job uses to fetch a track's analysis from the content node.

Changes

  • handler.go: add MetadataFloat64 accessor (bpm arrives as a JSON number).
  • validate.go: add validMusicalKeys map + isValidMusicalKey (mirrors is_valid_musical_key).
  • track_create.go: persist the five fields on insert, with invalid-key → NULL and zero/absent bpm → NULL.
  • track_row.go: load/merge/update/insert the five fields with the keep-on-zero/keep-on-invalid merge semantics.

Test plan

  • go build ./... + go vet clean (pkg/etl module)
  • Full entity_manager suite green against ephemeral Postgres (sequential -count=1 -p 1, 181s)
  • New tests: TestTrackCreate_PersistsBpmAndKey, TestTrackCreate_RejectsInvalidMusicalKey, TestTrackUpdate_PersistsBpmAndKey, TestTrackUpdate_KeepsBpmKeyOnZeroOrInvalid

🤖 Generated with Claude Code

The entity-manager track create/update handlers never wrote bpm,
musical_key, is_custom_bpm, is_custom_musical_key, or audio_upload_id,
so tracks indexed by go-etl lost these fields entirely. This matches
apps' discovery-provider populate_track_record_metadata:

- bpm: explicit null clears; a nonzero number sets; 0/absent/non-numeric
  keeps the existing value.
- musical_key: explicit null clears; a valid MusicalKey enum value sets;
  an invalid value keeps the existing value. Validated against the
  flats-only enum (e.g. "C# minor" is invalid; "D flat minor" is valid).
- is_custom_bpm / is_custom_musical_key / audio_upload_id: set when
  present, otherwise unchanged.

audio_upload_id is also what the repair_audio_analyses backfill job keys
on to fetch a track's analysis from the content node.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@raymondjacobson raymondjacobson changed the title fix(etl): persist track bpm/musical_key/audio_upload_id (python parity) fix(etl): persist track bpm/musical_key/audio_upload_id Jun 2, 2026
@raymondjacobson raymondjacobson merged commit dca79f0 into main Jun 2, 2026
5 checks passed
@raymondjacobson raymondjacobson deleted the fix/etl-track-bpm-musical-key-parity branch June 2, 2026 05:28
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