Per-band uploads: an entry is assembled from one file per band #11

Merged

hermes-agent merged 1 commit from feature/per-band-uploads into main

2026-10-25 22:17:43 +00:00

hermes-agent commented

2026-10-25 22:16:49 +00:00

Owner

Stacked on #10 (D). Merge #10 first.

The bug

EDI is natively one file per band, so an entrant submitting 2m and 6m sends two files for one submission. The re-upload path cleared every QSO and rebuilt from the newest file, so the second upload silently dropped the first band. Reproduced on a real Postgres database:

upload 1 (2m): entry 2 v1 -> 2 QSOs on 2m              score 2
upload 2 (6m): entry 2 v2 -> 1 QSO on 6m only           score 1

The 2m QSOs were gone from the entry (the raw file survived on disk, but nothing in the database referenced it any more).

The fix (owner decision: merge per band)

A file covering one band replaces that band's QSOs and keeps the others.
A file covering several bands (Cabrillo) is authoritative for the whole log and replaces every band, because it claims to describe the entire submission.
The merged log is rebuilt, rescored and reflagged as a unit, so Multiplier marks stay correct across bands (the same locator on two bands is two Multipliers, not one).
QSOs are kept in chronological order after the merge.
The PIN requirement is unchanged: a mismatched PIN still changes nothing.

Storage

New entry_log_file table records each upload with the band it covered (NULL = whole-log file). The raw files stay on disk as the recovery anchor (N2a), so the upload history is explicit instead of being implied by version numbers, and a rebuild knows which file belongs to which band.

Migration 0007 references the existing band/sourceformat Postgres enum types with create_type=False — creating them again fails with UndefinedTable/duplicate-type errors.

Verification

283 tests (up from 277), with six new tests covering: merge adds a band, same-band re-upload replaces only that band (no leftover duplicates), a multi-band file is authoritative, multipliers recomputed across bands, wrong PIN changes nothing, chronological ordering preserved.
Confirmed on the real database: the 6m-only entry, given a 2m file, came back as 2m + 6m with score 6 and anchors v3.edi (6m) and v4.edi (2m).

Docs

design.md 9 amended, a checklist amendment records the decision and its reason, handover baseline is 283.

Stacked on #10 (D). Merge #10 first. ## The bug EDI is natively one file per band, so an entrant submitting 2m and 6m sends two files for one submission. The re-upload path cleared every QSO and rebuilt from the newest file, so the second upload silently dropped the first band. Reproduced on a real Postgres database: ``` upload 1 (2m): entry 2 v1 -> 2 QSOs on 2m score 2 upload 2 (6m): entry 2 v2 -> 1 QSO on 6m only score 1 ``` The 2m QSOs were gone from the entry (the raw file survived on disk, but nothing in the database referenced it any more). ## The fix (owner decision: merge per band) - A file covering **one band** replaces that band's QSOs and keeps the others. - A file covering **several bands** (Cabrillo) is authoritative for the whole log and replaces every band, because it claims to describe the entire submission. - The merged log is rebuilt, **rescored and reflagged as a unit**, so Multiplier marks stay correct across bands (the same locator on two bands is two Multipliers, not one). - QSOs are kept in chronological order after the merge. - The PIN requirement is unchanged: a mismatched PIN still changes nothing. ## Storage New `entry_log_file` table records each upload with the band it covered (`NULL` = whole-log file). The raw files stay on disk as the recovery anchor (N2a), so the upload history is explicit instead of being implied by version numbers, and a rebuild knows which file belongs to which band. Migration `0007` references the existing `band`/`sourceformat` Postgres enum types with `create_type=False` — creating them again fails with `UndefinedTable`/duplicate-type errors. ## Verification - **283 tests** (up from 277), with six new tests covering: merge adds a band, same-band re-upload replaces only that band (no leftover duplicates), a multi-band file is authoritative, multipliers recomputed across bands, wrong PIN changes nothing, chronological ordering preserved. - Confirmed on the real database: the 6m-only entry, given a 2m file, came back as 2m + 6m with score 6 and anchors `v3.edi` (6m) and `v4.edi` (2m). ## Docs `design.md` 9 amended, a checklist amendment records the decision and its reason, handover baseline is 283.

hermes-agent added 1 commit

2026-10-25 22:16:49 +00:00

fix(ingest): merge per-band uploads instead of replacing the log b6f58e05f5

EDI is natively one file per band, so an entrant submitting 2m and 6m sends two
files for one submission. The re-upload path cleared every QSO and rebuilt from the
newest file, which silently dropped the other bands — reproduced on a real database:
a 2m file (2 QSOs, score 2) followed by a 6m file left the Entry holding one 6m QSO
and a score of 1.

Owner decision (2026-10-25): merge per band.

- A file covering one band replaces that band's QSOs and keeps the rest.
- A file covering several bands (Cabrillo) is authoritative for the whole log.
- The merged log is rebuilt, rescored and reflagged as a unit, so Multiplier marks
  stay correct across bands (same locator on two bands is two Multipliers).
- QSOs are kept in chronological order after a merge.
- Every upload is recorded in the new entry_log_file table with its band (NULL for a
  whole-log file); the raw files stay on disk as the recovery anchor, so the upload
  history is explicit rather than implied by version numbers.
- Migration 0007 creates the table; it references the existing band/sourceformat PG
  enum types with create_type=False rather than trying to create them again.

Docs: design 9 amended, checklist amendment recorded, handover baseline 283.
Tests: 283 (was 277) — merge adds a band, same-band re-upload replaces only that
band, a multi-band file is authoritative, multipliers recomputed, a wrong PIN still
changes nothing, ordering preserved.

hermes-agent changed target branch from feature/live-logging to main

2026-10-25 22:17:37 +00:00

hermes-agent merged commit e5b241d12e into main

2026-10-25 22:17:43 +00:00

hermes-agent referenced this pull request from a commit

2026-10-25 22:17:44 +00:00

Merge pull request 'Per-band uploads: an entry is assembled from one file per band' (#11) from feature/per-band-uploads into main