Mirror writes DJ legal names into tubafrenzy's public DJ_HANDLE for handle-less DJs

[jakebromberg]

Problem

mapShowToTubafrenzy in the legacy mirror computes the value written to tubafrenzy's public DJ_HANDLE field as:

// shared/legacy-mirror/src/http-mirror.ts:512 (pre-fix)
const djHandle = override && override.length > 0 ? override : dj.djName || dj.name;

The terminal dj.name is auth_user.name. That column is a hidden second copy of the DJ's legal name: dj-site's admin provisioning sends name: realName || username, the auth provision route stores it verbatim, and nothing ever maintains it afterwards (roster edits go straight to better-auth's admin.updateUser and touch real_name/dj_name only). The history is written up at shared/database/src/dj-name.ts:1-13 and :33-40.

So for every DJ who has not set a stage handle, starting a show writes their legal name into DJ_HANDLE.

This is the fifth dj_name-family writer. Commit 2a37bbc6 removed the auth_user.name fallback from what it described as "all 4 dj_name writers"; the mirror's outbound djHandle was not among them, and it has been reading name ever since.

Why it matters

• DJ_HANDLE is a public field. It renders on wxyc.info's playlist pages — the same class of exposure as PII leak: flowsheet ETL writes DJ_NAME (real name) into shows.legacy_dj_name, surfaced on v2 marker wire #1393.
• It round-trips back into Backend-Service: the flowsheet ETL reads tubafrenzy's DJ_HANDLE into shows.legacy_dj_name, so the leak also lands in our own database, where resolveShow's COALESCE chain can surface it on the v2 marker wire.
• It is actively writing today and keeps writing until the 2026-08-31 tubafrenzy turndown. Every handle-less DJ who starts a show in the remaining window adds a row that the final tubafrenzy dump scrub (tubafrenzy turndown data-finalization (BS side): final-dump one-shot sweeps + preservation #1543) and the shows.legacy_dj_name remediation would otherwise have to chase.

Two callers reach it: apps/backend/middleware/legacy/flowsheet.mirror.ts:168 (live show-start path) and jobs/legacy-mirror-reconcile/orchestrate.ts:285 (reconcile sweep 1). Both select() the full auth_user row, so no query change is needed.

Fix

djHandle resolves as: per-show override -> resolveDjDisplayName(djName) (the canonical helper in @wxyc/database, which trims and treats the literal "Anonymous" as absent) -> auth_user.username -> ''. It never reads name, and it does not re-derive the trim/Anonymous logic locally.

username is the terminal fallback rather than name: it is the least-surprising non-PII stable identifier and it matches the auth_user.name := handle, else username policy chosen for the broader safeguards work. MirrorDJ gains username?: string | null.

The all-absent case is pinned to '' (mirroring the sibling showName ?? '') rather than left as emergent undefined on a field tubafrenzy treats as required. It is unreachable in practice — every provisioned user has a username, and anonymous users cannot own shows.

Deliberately not changed: http-mirror.ts:514 (djName: dj.realName || dj.name). That targets tubafrenzy's separate DJ_NAME legal-name field, where name is still the correct fallback until the auth_user.name backfill makes real_name reliably populated. It is not the leak, and folding it in here would change a field this issue is not about.

Also corrects the shows.legacy_dj_name docblock at shared/database/src/schema.ts:2497-2510, which described the outbound chain this change removes — a stale doctrine comment on exactly this column is how the last incident propagated.

Scope

This is Track 0 of plans/dj-name-pii-safeguards.md — the "stop the live writer" slice, sized to ship alone and immediately. The plan file itself lands in a sibling PR; the rest of it (PII field registry, COMMENT ON COLUMN migration, the databaseHooks.user derivation choke point, the auth_user.name backfill, the wxyc/restricted-real-name lint rule, and the sentinel wire spec) is out of scope here.

Acceptance criteria

• mapShowToTubafrenzy's djHandle provably never reads name or realName, proven by a sentinel unit test across the override/handle/username/all-absent matrix.
• The all-absent case yields ''.
• http-mirror.ts:514 (DJ_NAME) is unchanged.
• Both callers' unit fixtures carry username.
• The shows.legacy_dj_name docblock no longer describes the removed chain.

[jakebromberg]

Fix opened as #2292 (branch bugfix/mirror-djhandle-pii), which carries Closes #2291.

It ships Track 0 alone: the djHandle chain at shared/legacy-mirror/src/http-mirror.ts:531-532, MirrorDJ.username, the sentinel + matrix unit tests in tests/unit/middleware/legacy/http.mirror.test.ts, the username fixture in tests/unit/jobs/legacy-mirror-reconcile/orchestrate.test.ts, and the shows.legacy_dj_name docblock correction at shared/database/src/schema.ts:2497-2510. :534 (DJ_NAME) is left untouched, as described above.

[jakebromberg]

This falsifies a load-bearing claim in the final-dump capture spec (2026-08-27)

This issue's body already notes that every handle-less DJ starting a show "adds a row that the final tubafrenzy dump scrub (#1543) … would otherwise have to chase." There is a sharper consequence worth naming here, because it lives in a document this issue doesn't reference.

plans/tubafrenzy-final-dump-capture-spec.md — which governs the permanent S3 archive of tubafrenzy and every downstream repair pass — states as its PII rule:

Any import path reads DJ_HANDLE, never DJ_NAME […] The column name in FLOWSHEET_RADIO_SHOW_PROD that is safe to read is DJ_HANDLE.

Per this issue, that is exactly backwards for handle-less DJs. The spec certifies the contaminated column as the safe one and directs every future import path at it — including the paths that feed shows.legacy_dj_name, which reaches the public v2 wire through the COALESCE chain. So the rule as written does not prevent the republication it was authored to prevent; it routes it.

Filed as WXYC/wiki#123 (sev:high, effort:s), wired as a blocker on #1543 and added to org Project #36. It is time-boxed the same way this issue is: the dump is taken at last-write, days from now, and cannot be re-taken.

PR #2292 stops new contaminated rows and should land regardless — but it cannot clean rows already written, and there is no reverse path from Backend into MySQL. The spec correction is the part that protects the consumers.