Public archive renders 354 DJ identities for 311 DJs: case-fold duplicates, multi-token co-host composites, 96 nameless shows, and 41 raw HTML entities

[jakebromberg]

Revised 2026-09-09. The original body claimed a stored-vs-served discrepancy that does not exist, and understated three of the four defects. Both corrected below; the investigation that produced the corrections is in this comment. Figures are now from a 40-week scan rather than a 12-week one.

Problem

The DJ identity served on the public playlist archive renders 354 distinct strings for 311 distinct DJs. One DJ appears as two different people, co-hosted shows attribute to a single fabricated composite handle, 4% of shows are nameless, and a cohort of shows renders raw HTML numeric character references as literal text. None of this blocked the tubafrenzy cutover; all of it makes the archive — and any roster query built on it — quietly wrong.

This became listener-visible on 2026-09-08, when WXYC/website#233 restored wxyc.org/playlists/archive (~1,546 req/day plus its ~1,906/day drill-in) and wxyc.org/airplay-search (~181/day). Both render this data.

Measured 2026-09-09 against production

Via GET https://api.wxyc.org/flowsheet/range over 40 consecutive 7-day windows, 2025-12-03 → 2026-09-09 PT — 2,399 shows, 354 distinct non-null dj_name values. Reproducible with the script in "Notes for implementer". These figures postdate the #2281 scrub of 2026-09-08.

1. Case-fold duplicates — 38 collisions across 354 names. Same DJ, two identities. Three of the 38 are three-way rather than two-way. A twelve-week slice of the same method gives 17 collisions across 177 names, so this scales with the window rather than being a fixed backlog. Examples:

annie / Annie                      DJ Diggler / DJ DIGGLER
augustine / Augustine              dj eureka! / DJ Eureka!
dj almost famous / DJ Almost Famous    Dj Made to Measure / DJ Made to Measure
DJ Beaux / DJ BEAUX                dj mothership / DJ Mothership
DJ blue / DJ Blue                  dj ovni / DJ OVNI
Dj Derpa / DJ Derpa                DJ shadowboxer / DJ Shadowboxer

A listener browsing the archive sees DJ Diggler and DJ DIGGLER as two DJs, and a roster query counting distinct DJs over-counts by 38. This is also what made the pre-cutover accountless-DJ cohort measurement need hand-deduplication.

2. Co-host shows collapse two DJs into one string, using four different join tokens. 20 distinct composite strings across 34 shows in the 40-week scan:

Join token	distinct composites
and	7
&	6
+	4
,	3

Commas are the minority form — an earlier version of this ticket treated this as a comma problem, and a splitter written to that assumption would miss most of the cohort. Upstream since 2025-01-01 the ratio is 42 ampersand-joined shows against 15 comma-joined.

The same pair is not stable across shows. Dj double hockey sticks & dj palomita (5 shows) and dj palomita + dj double hockey sticks (6 shows) are the same two people under a different token and a different order. Splitting on all four tokens is necessary but not sufficient; member order has to be canonicalized before pairs will match each other.

Neither DJ in a composite is findable by searching their own name, and each composite is a phantom entry in every distinct-name list.

3. Nameless shows — 96 of 2,399 (4.0%). dj_name is null on the show record, so the archive renders a show with no attribution. The twelve-week slice gives 15 of 695, so this is a rate rather than a backlog — any acceptance criterion should name a window or say "all history".

4. A real HTML-entity cohort — 41 shows, and it is upstream. DJ_HANDLE values carrying numeric character references, e.g. DJ 4𝄽. They run 2012-04 to 2022-07 PT and stop dead there, which reads like a pre-UTF-8 JSP form encoding non-Latin-1 input on submit. These pass through to the current wire unchanged — GET /flowsheet/range for 2022-07-10 → 07-17 returns shows 62312 and 62359 with dj_name = DJ 4𝄽, so wxyc.org/playlists/archive renders the literal entity text today. Finite, frozen, and the only place in the DJ-name data where HTML entities actually exist.

Investigated and closed: there is no stored-vs-served discrepancy

An earlier version of this ticket asserted that dj pipe dreams & dj slime and a Dj digitalprincess whitespace variant appeared in the stored column but not in the served output. That was wrong on both counts.

Checked 2026-09-09 against tubafrenzy DJ_HANDLE (as hex), GET /flowsheet/range over 40 weeks, and flowsheet.dj_name via a byte-equality dj:"…" search. All three agree. The & was an escaping artifact of the runbook write-up this ticket was drawn from — the stored and served value is dj pipe dreams & dj slime with a bare ampersand, and the show (1951243, 2026-08-30) is inside the original twelve-week window and is served; the earlier claim that the API returned dj pipe dreams for it was a scan-pattern error, not a data finding. Dj digitalprincess has exactly one byte form across all 28 upstream shows, all 16 served shows, and all 45 stored entry rows for her two most recent shows — one classic-origin, one dj-site-native.

shows.legacy_dj_name is a verbatim copy of the upstream DJ_HANDLE and is authoritative for the legacy cohort. The sharpest evidence is a corrupted row: upstream has exactly two mojibake handles in its whole history (two consecutive shows on 2025-11-17 where Dj Fabergé is stored as Dj Faberg + a double-encoded U+FFFD), and /flowsheet/range serves them with those exact bytes while the preceding show that day carries the correct value. Backend reproduces upstream faithfully enough to preserve a defect it could have papered over.

One residual, stated rather than hidden: if the Dj digitalprincess observation came from an aggregated query rather than the per-show one, a byte difference could still hide in auth_user.dj_name, the one column whose whitespace the API trims away on every read path. Closing that needs a single query against Backend Postgres, which was not reachable: SELECT id, dj_name, length(dj_name), md5(dj_name) FROM auth_user WHERE dj_name ILIKE '%digitalprincess%';

Why this is a bounded, closing window

The upstream writer is dead. The tubafrenzy flowsheet webhook — sole filler of shows.legacy_dj_name per #1858 — was disabled 2026-09-07 19:50 PDT as Phase 6a step E4 (WXYC/wiki#88). No new rows of this shape can be created. This is a finite, frozen cohort, not an ongoing leak.

But the ground truth has a shelf life. The only source that can disambiguate a co-host composite or a case variant is tubafrenzy's wxycmusic MySQL, queryable until Phase 6b (WXYC/wiki#94, dateless) and after that surviving only as the archived dump from #1543.

Desired end state

The archive renders one identity per DJ. Case variants of one handle resolve to one displayed name, co-hosted shows either attribute to both DJs or are explicitly marked as co-hosted rather than carrying a fabricated composite handle, nameless shows carry their upstream handle or a deliberate label, and the 41 numeric-character-reference handles render as the characters they encode.

Part of this is a policy question, not a repair. Case-folding DJ blue to DJ Blue picks a winner among a DJ's own self-typed spellings. Deciding which spelling is canonical — most recent, most frequent, or the account's dj_name where one exists — should be settled before the migration, not inside it.

Where

• shows.legacy_dj_name, shows.dj_name, flowsheet.dj_name (Backend Postgres, wxyc_schema)
• resolveShowDjName / resolveDjDisplayName — shared/database/src/dj-name.ts
• resolveShow — apps/backend/routes/internal.route.ts (writes COALESCE(auth_user.dj_name, shows.legacy_dj_name) onto marker rows)
• buildDjNameMatch — apps/backend/services/search.service.ts (a quoted dj:"…" term compiles to byte equality against flowsheet.dj_name, which is the probe used above)
• Read paths: GET /flowsheet/range, GET /flowsheet/playlist, GET /flowsheet/search
• Consumers: wxyc.org/playlists/archive, wxyc.org/airplay-search, the iOS/Android v2 playlist
• Ground truth: FLOWSHEET_RADIO_SHOW_PROD.DJ_HANDLE in tubafrenzy wxycmusic
• Regenerating queries: plans/cutover-gate.sql, plans/cutover-roster.sql

Constraints

• flowsheet.dj_name is a denormalized second copy on every entry row, and it is what /flowsheet/search matches. Any canonicalization migration must update both it and shows.legacy_dj_name, or the archive listing and the search results will disagree about the same DJ. Convert flowsheet-etl and the tubafrenzy webhook's dj_name writes from a re-derived COALESCE to the canonical resolveShowDjName helper #2313's COALESCE re-derivation is the mechanism by which the two drift.
• DJ_NAME in tubafrenzy is the DJ's real name and is PII. DJ_HANDLE is the on-air alias by convention only — Mirror writes DJ legal names into tubafrenzy's public DJ_HANDLE for handle-less DJs #2291 established the mirror wrote legal names into it for handle-less DJs, so it is not a safe source without filtering. Never import a real name into a public column. See WXYC/wiki#123.
• Do not undo Scrub historical denormalized dj_name values to match the current resolution policy #2281. That scrub ran 2026-09-08 and rewrote 1,103,206 rows to remove Cohort A/B real names. Cohort C — real names DJs typed into DJ_HANDLE themselves — remains by design, and 994 of 995 affected shows were verified to have been public on tubafrenzy already. A "clean up the names" migration that touches Cohort C re-litigates a settled decision.
• Any bulk UPDATE on flowsheet must respect the 2-second bridge budget. The 2026-09-08 scrub breached it and returned 503 on 42% of /recentEntries requests for 43 minutes (see Scrub historical denormalized dj_name values to match the current resolution policy #2281). Sample http://wxyc.info/playlists/recentEntries?v=2&n=50 during the drain, not only before and after. flowsheet carries a STORED GENERATED tsvector column and migration 0053 wedged on locks once (Migration 0053 wedge: split DDL from backfill, harden migration runner #511).
• Run a SELECT with the same WHERE clause and confirm the row count before any UPDATE.

Acceptance criteria

Restructured 2026-09-10 per the three-treatments decision: case variants fold with no writes, the 41 entities are repaired, composites are deferred. There is deliberately no canonical-spelling criterion.

Case variants — fold for aggregation, write nothing

• A fold_dj_name equivalent exists and is used for grouping, reusing foldArtistName / wxyc_schema.fold_artist_name semantics rather than inventing new ones. Do not re-litigate Unicode-form artist duplication at the catalog write boundary (artistIdFromName) #1897's decisions (accent-folding, non-decomposing letters deliberately unfolded).
• It is backed by a functional index built CONCURRENTLY, following migration 0134's pattern, and EXPLAIN confirms an index scan.
• Grouping the 40-week scan by the folded key yields one entry per DJ: fold-distinct count == displayed count.
• Every reader folds identically — archive listing, drill-in, and search. Quoted (exact) search terms are case-sensitive: exact mode uses = where every other predicate uses ILIKE #2398 (exact mode uses = where the rest folds) is a prerequisite, not a neighbour.
• No row of shows.legacy_dj_name or flowsheet.dj_name is rewritten for a case variant.

The 41 numeric character references — repair

• All 41 upstream DJ_HANDLE values carrying numeric character references render as the characters they encode, verified against two known shows (62312, 62359).
• Both shows.legacy_dj_name and flowsheet.dj_name are updated, or the archive listing and search will disagree about the same DJ.
• A SELECT with the same WHERE clause confirms the row count before the UPDATE.
• The write respects the /recentEntries 2 s bridge budget — sampled during the run, not only before and after. At 41 shows this should be trivial, which is itself worth confirming rather than assuming.

Cross-cutting

• No row that Scrub historical denormalized dj_name values to match the current resolution policy #2281 classified as Cohort C is modified.
• No new real name reaches a public column; spot-checked against the roster.

Explicitly out of scope

• Co-host composites (20 strings / 34 shows, four join tokens). Representation belongs to [Epic] Go Live must not silently co-host — takeover prompt, sign-out close, operator close #2232 / A co-host cannot leave a show: the duplicate-join guard swallows the intent contract #2405.
• Any canonical-spelling policy for case variants.

Notes for implementer

The scan that produced the figures above (no auth required; /flowsheet/range rejects windows wider than ~7 days with a 400):

NOW=$(python3 -c "print(int(__import__('time').time()*1000))")
for w in $(seq 1 40); do
  E=$((NOW - (w-1)*7*86400000)); S=$((E - 7*86400000))
  curl -s "https://api.wxyc.org/flowsheet/range?start=$S&end=$E" \
    | jq -r '.shows[]? | "\(.id)\t\(.dj_name // "NULL")"'
done > djname-scan.txt

Then group by unicodedata.normalize("NFKC", " ".join(n.split())).casefold() and report groups of size > 1. Detect composites on all of &, , , and, + — a comma-only pattern finds 3 of the 20.

Worth checking whether wxyc.org/airplay-search's DJ-name search is case-sensitive — if it is, these variants also split search results, compounding the problem on the surface that was just restored. #2398 reports exact-mode search using = where the rest of the system folds, and #2400 reports every dj_name search being a full seq scan; both are adjacent to this on the same restored pages.

Related

• Scrub historical denormalized dj_name values to match the current resolution policy #2281 — the dj_name PII scrub; defines Cohorts A/B/C and what must not be touched
• Convert flowsheet-etl and the tubafrenzy webhook's dj_name writes from a re-derived COALESCE to the canonical resolveShowDjName helper #2313 — flowsheet-etl re-derives dj_name with a COALESCE instead of the canonical helper; the mechanism by which the two copies drift
• mu-Ziq renders as U+FFFD in the app: close Phase 4's flowsheet gap and repair the residue #2382 — μ-Ziq U+FFFD residue; the same mojibake class that appears in the two 2025-11-17 Dj Fabergé handles
• Mirror writes DJ legal names into tubafrenzy's public DJ_HANDLE for handle-less DJs #2291 — DJ_HANDLE holds legal names for handle-less DJs
• Tubafrenzy webhook insert omits dj_name on show_start/show_end rows (118,919 affected, ongoing) #1371, PII leak: flowsheet ETL writes DJ_NAME (real name) into shows.legacy_dj_name, surfaced on v2 marker wire #1393, Flowsheet ETL: shows.legacy_dj_name occasionally not populated even when tubafrenzy has DJ_NAME #605 — prior legacy_dj_name population defects
• Quoted (exact) search terms are case-sensitive: exact mode uses = where every other predicate uses ILIKE #2398, Every dj_name search is a full seq scan of the flowsheet heap against a 5s timeout #2400 — search behaviour on the same restored archive pages
• Restore the two reverted D3 listener surfaces once the dj_name scrub lands (deferred past the turndown) website#232, Restore the airplay-search and playlist-archive listener surfaces website#233 — the restoration that made this listener-visible
• WXYC/wiki#88 — Phase 3; the webhook shutdown that froze this cohort
• WXYC/wiki#94 — Phase 6b; when live ground truth stops being queryable
• WXYC/wiki#95 — Phase 7 schema cleanup, where this was originally slated

[jakebromberg]

Acceptance criterion 1 — there is no stored-vs-served discrepancy

Neither of the two observations in the "fourth defect" section survives byte-level checking. The & is not a value in shows.legacy_dj_name; it is an escaping artifact introduced while writing it up. Dj digitalprincess has exactly one byte form in every layer that can be observed. No layer introduces or masks anything here, so there is no layer-choice risk for the repairs the rest of this ticket describes, and nothing to migrate for this criterion. I'd suggest replacing that section with the paragraph at the bottom of this comment.

Everything below was measured 2026-09-09 morning PT, read-only, and therefore reflects the state after the #2281 scrub of 2026-09-08 — worth stating because the original measurement predates it.

What was tested

Three layers, compared as raw bytes rather than as rendered text:

1. Upstream — tubafrenzy wxycmusic.FLOWSHEET_RADIO_SHOW_PROD, SELECT HEX(DJ_HANDLE) over a --default-character-set=utf8 connection. DJ_NAME was never selected.
2. Served (show side) — GET https://api.wxyc.org/flowsheet/range over 40 consecutive 7-day windows, 2025-12-03 → 2026-09-09 PT: 2,399 shows, 354 distinct non-null dj_name strings. Raw JSON kept per window so the analysis is re-runnable without refetching.
3. Stored (entry side) — GET /flowsheet/search with a quoted dj:"…" term. That compiles to flowsheet.dj_name = $1 (buildDjNameMatch, apps/backend/services/search.service.ts), i.e. a byte-equality predicate against the stored column, unwindowed, across all history. Comparing its total against the unquoted ILIKE-contains form of the same term detects an invisible variant that rendering would hide.

Defect A — dj pipe dreams & dj slime

The show exists, it is inside the twelve-week window, and it is served. The scan in the issue body should have found it; the claim that the API returns dj pipe dreams for it is wrong.

Layer	Value	Evidence
tubafrenzy DJ_HANDLE, show 172850, signed on 2026-08-30 09:05 PT	dj pipe dreams & dj slime	HEX = 646A207069706520647265616D73 202620 646A20736C696D65 — the middle group is a bare &, not &
GET /flowsheet/range, show 1951243, start_time 2026-08-30T16:05:30Z (09:05 PT)	dj pipe dreams & dj slime	present in the 2026-08-27 → 09-03 window
flowsheet.dj_name, show_start marker entry 5313444	dj pipe dreams & dj slime	served on the v2 marker projection
flowsheet.dj_name, byte-equality probe	matches	dj:"dj pipe dreams & dj slime" → 200; dj:"dj pipe dreams & dj slime" → no match

The marker row is the load-bearing one. resolveShow in apps/backend/routes/internal.route.ts writes COALESCE(auth_user.dj_name, shows.legacy_dj_name) onto marker rows at webhook time. This show has no linked account: query B of plans/cutover-gate.sql, the query the measurement came from, filters primary_dj_id IS NULL, so every handle it can report has none by construction. With no user row that COALESCE resolves to shows.legacy_dj_name — and it produced a bare &. That is a direct read of the column's bytes through a second, independent path, and it agrees with upstream.

The same conclusion falls out of the resolver without needing the marker row. resolveShowDjName (shared/database/src/dj-name.ts) contains no unescaping and no normalization; with primary_dj_id == null it returns legacy_dj_name verbatim, after an override check. That is the same expression cutover-gate.sql query B computes (btrim(COALESCE(dj_name_override, legacy_dj_name)) under primary_dj_id IS NULL). For any row that query can return, its output and /flowsheet/range's dj_name are the same bytes. They cannot disagree on an &.

I also grepped the write path end to end and there is no escaper in it. StartRadioShowServlet stores request.getParameter("djHandle").trim(). BackendServiceWebhookClient puts the raw stored handle on the payload (explicitly, per its own comment). TextSanitizer.sanitize strips entities and normalizes Unicode but never emits one. On the Backend side the only HTML escapers are services/slack/builder.ts and jobs/metadata-no-match-digest/format.ts, neither of which is on this path.

Conclusion: the & originated in the write-up, not the database. It appears twice in plans/tubafrenzy-cutover-runbook-20260907.md — once in the gate-artifact paragraph and once in the data-quality paragraph the issue body was drawn from — and the issue inherited it. I could not reconstruct the exact step that escaped it and am not going to guess.

Defect B — Dj digitalprincess as two rows

There is no whitespace or Unicode variant in any column I can read.

• Upstream: 28 shows carry this handle, from 2025-02-20 to 2026-09-01 PT. All 28 hex to 446A206469676974616C7072696E63657373 — one byte form, no leading/trailing space, no NBSP.
• Served: 16 shows in the 40-week scan, all byte-identical to the above. Those 16 correspond 1:1 to the 16 upstream shows in the same span.
• Stored: for both of her most recent shows, exact = and ILIKE-contains return the same totals — 22 entry rows on 2026-09-01 and 23 on 2026-08-18, every one matching Dj digitalprincess byte-for-byte. This is the interesting pair, because the 09-01 show is dj-site-native and the 08-18 show is classic, so both sides of the new/classic split were checked and both agree.

The most likely explanation for the observation is that it came from cutover-gate.sql query D, which is the one query in that file that is not aggregated — it emits one row per show. She has exactly two shows in query D's window (Mon 19:00 → Tue 09:00 ET, last 35 days): 2026-09-01 08:05 ET and 2026-08-18 07:59 ET, both Tuesday mornings, both inside the isodow = 2 AND hour < 9 arm. Two rows, identical strings, two shows, no variant. That is inference — I don't know which query was actually on screen — but it fits without requiring a defect.

The one thing I could not close. If the two rows came instead from an aggregated query — cutover-roster.sql Q2 groups by COALESCE(dj_name_override, u.dj_name, legacy_dj_name) and, unlike cutover-gate.sql query B, does not btrim — then a real byte difference must exist, and there is exactly one column it could hide in: auth_user.dj_name. That column is the only input to the chain whose leading/trailing whitespace the API removes, via resolveDjDisplayName's .trim(), and flowsheet.dj_name is written through that same trimming chain (resolveDjNameForShow → resolveShowDjName), so neither of my stored-side probes can see it. An untrimmed value is reachable in principle: complete-onboarding.ts trims, but the admin provisioning path (apps/auth/app.ts → provisionUser) passes djName through without trimming, and there is no DB-level constraint. Settling this needs one query against Backend Postgres, which I could not reach: SELECT id, dj_name, length(dj_name), md5(dj_name) FROM auth_user WHERE dj_name ILIKE '%digitalprincess%';. If it comes back a single trimmed row, defect B is closed as a query artifact.

Which value is authoritative

For this cohort, upstream and stored are the same value, so the question is less loaded than the ticket assumed — but for the record: tubafrenzy FLOWSHEET_RADIO_SHOW_PROD.DJ_HANDLE is authoritative, and shows.legacy_dj_name is a faithful verbatim copy of it (modulo truncate(_, 128)). The webhook copies the handle byte-for-byte. Where legacy_dj_name reaches the wire, it does so untransformed — resolveShowDjName deliberately does not even trim it on the primary_dj_id == null branch, per its own comment about not changing a single byte on the existing wire. There is no layer in between that could make one more correct than the other.

The sharpest evidence for that fidelity is a corrupted row. Upstream has exactly two mojibake handles in its entire history — two consecutive shows on 2025-11-17 where Dj Fabergé was stored as Dj Faberg + C3 AF C2 BF C2 BD (a double-encoded U+FFFD; the #2382 class, present in DJ handles as well as artist names). GET /flowsheet/range serves shows 73522 and 73523 with those exact bytes, while the immediately preceding show that day, 73521, carries the correct Dj Fabergé on both sides. Backend reproduces upstream faithfully enough to preserve a defect it could have papered over, which is the behaviour you want from a mirror and the reason upstream stays the arbiter.

What this changes for the rest of the ticket

Criterion 1 resolves to "no discrepancy", which removes the stated blocker on writing the migration. The practical consequence is that the repair target is unambiguous: shows.legacy_dj_name is what the archive renders for the legacy cohort, editing it changes what listeners see, and there is no second copy that will silently disagree. The one real caveat is flowsheet.dj_name, which is a denormalized copy on every entry row and is what /flowsheet/search matches — #2313's COALESCE re-derivation is the mechanism by which the two drift. Any canonicalization migration has to update both, or the archive listing and the search results will disagree about the same DJ.

Three things the ticket understates

Not asking for scope creep, but they change the shape of criteria 3–5 and are cheap to record now while ground truth is still queryable.

Case collisions are ~2.2× the reported count over a longer window. The twelve-week figures reproduce (695 shows, 177 distinct, 160 fold-distinct, 17 collisions — sampling drift against the 706 in the body). Extending the identical method to 40 weeks: 2,399 shows, 354 distinct names, 311 fold-distinct, 38 collisions. Three of the 38 are three-way rather than two-way. The list regenerates from the script already in the body with the loop bound widened.

Co-host composites use four different join tokens, not one. The body treats this as a comma problem; commas are the minority form. In the 40-week API scan there are 20 distinct composite strings across 34 shows, joined by & (6 of the 20), , (3), and (7) and + (4). Upstream since 2025-01-01 there are 42 shows with an ampersand-joined handle against 15 with a comma-joined one. And the same co-host pair is not stable across shows: one pair appears as Dj double hockey sticks & dj palomita (5 shows) and as dj palomita + dj double hockey sticks (6 shows) — different token, different order, same two people. A splitter that only handles commas will miss most of the cohort, and one that splits on all four still has to canonicalize member order before the pairs will match each other.

There is a real HTML-entity defect in DJ handles — just not the one in the body, and it is upstream. 41 shows all-time carry numeric character references in DJ_HANDLE, e.g. DJ 4𝄽. They run 2012-04 to 2022-07 PT and stop dead there, which reads like a pre-UTF-8 JSP form encoding non-Latin-1 input on submit. Zero of the 41 are &. They pass through to the current wire unchanged: GET /flowsheet/range for 2022-07-10 → 07-17 returns shows 62312 and 62359 with dj_name = DJ 4𝄽, so wxyc.org/playlists/archive renders the literal entity text today. If a decoding pass is in scope for the eventual migration, this is the cohort it applies to, it is finite and frozen, and it is the only place in the DJ-name data where HTML entities actually exist.

Nameless shows scale with the window as expected: 15 of 695 over twelve weeks, 96 of 2,399 (4.0%) over forty. So criterion 5's "19 shows" is a window-scoped count, not a fixed backlog — worth phrasing the criterion against a defined window or against all history.

Suggested replacement for the "fourth defect" section

Investigated and closed: there is no stored-vs-served discrepancy. Checked 2026-09-09 against tubafrenzy DJ_HANDLE (hex), GET /flowsheet/range over 40 weeks, and flowsheet.dj_name via byte-equality search. All three agree. The & was an escaping artifact of the runbook write-up — the stored and served value is dj pipe dreams & dj slime with a bare ampersand, and the show (1951243, 2026-08-30) is inside the twelve-week window and is served. Dj digitalprincess has exactly one byte form across all 28 upstream shows, all 16 served shows, and all 45 stored entry rows for her two most recent shows. shows.legacy_dj_name is a verbatim copy of the upstream handle and is authoritative for the legacy cohort; note that flowsheet.dj_name is a denormalized second copy of the same value, and any canonicalization migration must update both or search and the archive listing will disagree.

[jakebromberg]

Decision 2026-09-10: three defects, three treatments. No canonical-spelling policy, and no million-row rewrite.

This ticket asked one policy question — which spelling is canonical — for what are really three unrelated defects. Decided to split them, because only one of the three clearly warrants writing to the database at all.

Case variants (38 collisions) — fold for aggregation, write nothing

dj ovni and DJ OVNI are both genuinely that DJ. The harm is not in the stored bytes, it is in grouping: listings and roster counts render one person as two. Folding fixes grouping, so fold and leave the source text alone.

Reuse the existing machinery rather than inventing any: foldArtistName is already exported from @wxyc/shared as the TypeScript twin of wxyc_schema.fold_artist_name(text), and the pattern — accent-folding via lower(regexp_replace(normalize(x, NFD), '[combining marks]', '', 'g')), backed by a functional index (artists_fold_name_idx, migration 0134, IMMUTABLE, built CONCURRENTLY) — is settled, tested, and EXPLAIN-confirmed on PG14 and PG18. Its semantics were deliberated in #1897 and should not be re-litigated here; note in particular that non-decomposing letters (ß, ł, dotless ı) are intentionally not folded, a safe under-merge direction pinned by tests.

What does not transfer: the artist fix pairs that fold with jobs/artist-unicode-dedup, which merges duplicate rows by repointing 11 FKs, and the surviving row then supplies the display name. A legacy DJ handle is denormalized text with no entity row to merge into, so there is no merge half here. Only the matching half applies.

The real risk, stated plainly: a read-time fold is only correct if every reader folds identically — the archive listing, its drill-in, and search. #2398 already reports exact-mode search using = where the rest of the system folds, so that inconsistency exists today and this decision puts weight on it. Treat #2398 as a prerequisite rather than a neighbour.

The 41 numeric character references — repair them

DJ 4𝄽 and its 40 siblings, 2012-04 to 2022-07 PT, originating upstream in tubafrenzy's DJ_HANDLE, still rendering as literal entity text on the restored archive. This is the one defect where the correct value is not in dispute and the cohort is finite and frozen. Decode it.

Co-host composites (20 strings / 34 shows) — explicitly deferred, not forgotten

Four join tokens (and 7, & 6, + 4, , 3), and the same pair recurring under different tokens and different member orders. Splitting these is not a string problem: it requires deciding how a show with two DJs is represented, and inventing a splitter here would bake in an answer that belongs to the co-host work (#2232, #2405). Out of scope for this ticket. Recorded so the next reader does not take the silence for an oversight.

Mechanics worth knowing before implementing

• Show headings resolve at read time. resolveShowDjName's precedence is dj_name_override → legacy_dj_name (when primary_dj_id is NULL) → the account's name, so shows.dj_name_override outranks legacy_dj_name even for the legacy cohort. That is the column used to re-attribute show 1951325 by hand during the 2026-09-08 incident.
• Entry rows do not. flowsheet.dj_name is denormalized at play time and is what /flowsheet/search matches (DJ_NAME_EXPR, apps/backend/services/search.service.ts:105). An override set later does not retroactively reach it. Any entry-level change is a write pass, which is exactly what Scrub historical denormalized dj_name values to match the current resolution policy #2281's scrub had to be.

Consequence: the entity decode touches both columns for 41 shows' worth of rows, and the case-variant fold touches neither.