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