Slug generation can return an empty string for non-Latin / punctuation-only names

[chiptus]

Problem

Slug generation drops every non-[a-z0-9] character. For a name with no ASCII alphanumerics — non-Latin artist/stage names (e.g. サカナクション, Чайф) or punctuation-only input — the slug collapses to an empty string "".

This is a pre-existing issue, but the schedule-ingestion PR (#31) makes it newly fatal: the new artists_slug_unique constraint means two artists that both slugify to "" collide hard, and an empty slug also breaks slug-based .single() lookups (e.g. useSetBySlug).

Affected code

The same logic is duplicated in three places and any fix must keep them consistent:

• src/lib/slug.ts — generateSlug
• supabase/functions/diff-schedule/helpers.ts — toSlug
• supabase/migrations/20260509142022_commit_schedule_rpc.sql — commit_schedule__slugify

Suggested fix

Guarantee a non-empty result. When the slug would be empty, fall back to a deterministic value derived from the original name (e.g. an md5(name)-based suffix/prefix) so the same name always produces the same slug across frontend, Edge, and SQL. Alternatively, broaden the allowed character set consistently in all three implementations.

Update — partial mitigation landed in #31

PR #31 now rejects artist/stage names with no [a-z0-9] at CSV parse time (parseScheduleCsv), with a clear message, so the empty-slug case can't reach the importer. This issue stays open for the proper cross-cutting fix (a guaranteed-non-empty slug) so other entry points — manual artist/stage creation — are covered too.

Related: distinct names colliding on one slug

Separate from empty slugs: two genuinely different names can slugify to the same value (e.g. "DJ Tennis" vs "DJ.Tennis"), silently linking them to one artist/stage. The same hash-fallback / disambiguation work should account for this case.

Context

Split out of PR #31 review (Copilot comments on helpers.ts toSlug and commit_schedule__slugify, plus the external review's slug-collision note). Deferred from that PR because the fix is cross-cutting and changes app-wide slug behavior beyond schedule import.

[chiptus]

Residual gap: the parse-time guard is frontend-only

Following up on the "partial mitigation landed in #31" note — worth recording that the guard is asymmetric.

hasSluggableChars runs inside parseScheduleCsv (the browser wizard). The diff-schedule Edge Function's csvRowSchema does not re-check it — artists/stage are only validated with z.string().trim().min(1). So a direct, non-wizard caller of diff-schedule can still send a punctuation-only / non-Latin name, the diff produces an empty slug, and it fails opaquely later at commit-schedule (artistSlugs min(1)) — exactly the failure mode the mitigation was meant to remove.

It's admin-only and authed, so low severity, but the guard belongs at the trust boundary (the Edge Function), not just the client.

Cheap interim fix until the proper cross-cutting slug fix lands: mirror the check in diff-schedule/index.ts, e.g.

const sluggable = (s: string) => /[a-z0-9]/i.test(s);

const csvRowSchema = z.object({
  artists: z.array(z.string().trim().min(1).refine(sluggable, "name has no letters or digits")).min(1).transform(dedupeArtists),
  stage: z.string().refine(sluggable, "stage name has no letters or digits").optional(),
  // ...
});

The real fix in this issue (guaranteed-non-empty deterministic slug across slug.ts / toSlug / commit_schedule__slugify) makes this refine unnecessary, since empty slugs would no longer be possible — so treat the snippet above as a stopgap, not the resolution.

---

Generated by Claude Code

[chiptus]

This was generated by AI during triage.

Triage: bug · ready-for-human

Verified — all three implementations still share the [^a-z0-9]+ collapse that yields "" for non-Latin / punctuation-only names:

• src/lib/slug.ts — generateSlug
• supabase/functions/diff-schedule/helpers.ts:1–7 — toSlug
• supabase/migrations/20260522000000_commit_schedule_rpc.sql:9–22 — commit_schedule__slugify (the issue cites 20260509142022_commit_schedule_rpc.sql; the actual file is 20260522000000_… — stale reference)

The "newly fatal" premise holds: 20260522000001_add_artists_slug_unique.sql adds the artists_slug_unique constraint, so two names that both slugify to "" collide hard. The #31 mitigation only guards the CSV importer at the client — manual artist/stage creation remains exposed, and an empty slug also breaks slug-based .single() lookups (useSetBySlug).

Why ready-for-human, not ready-for-agent:

1. Design decision required — hash-fallback (e.g. md5(name)-derived) vs. broaden-charset. The issue sketches the former but doesn't commit.
2. Cross-language byte-consistency — whichever scheme is chosen must produce the same output in browser JS, Deno Edge, and Postgres SQL, or the frontend and the committed row disagree on the slug and lookups silently break. That's the delicate part.
3. Scope isn't crisp — a second concern is folded in (distinct names colliding on one slug, DJ Tennis vs DJ.Tennis); worth deciding whether it's in scope for the same fix.

Well-understood and high-value, but wants a maintainer to set the approach before implementation.

---

Generated by Claude Code