Skip to content

Normalize usernames for safe, indexed user lookup #185

Description

@coder13

Goal

Make usernames a reliable, privacy-safe key for friend discovery before search and public profiles depend on them.

Why this is needed

The current username update path performs a case-insensitive regular-expression lookup without a database uniqueness guarantee. Social search needs deterministic casing, safe query handling, predictable conflicts, and an indexed prefix lookup.

Product contract

  • Usernames remain optional, but an authenticated user needs a valid username before other users can find them by username.
  • Matching is case-insensitive while preserving the user's chosen display casing.
  • Username and explicitly visible WCA ID are the only MVP discovery identifiers.
  • Email is never a lookup key, accepted search mode, fallback, or existence signal.
  • Existing usernames are preserved where possible; collisions are surfaced for explicit resolution rather than silently renamed.

Acceptance criteria

  • Define one server-side normalization and validation function and reuse it for writes and search.
  • Store a normalized username field with a sparse unique index; preserve the display value separately.
  • Audit/backfill existing users with a dry-run mode that reports normalization collisions before the unique index is applied.
  • Replace regex interpolation with an escaped, indexed exact/prefix lookup and cap result counts.
  • Return stable validation responses, including 400 for invalid input and 409 for a case-insensitive conflict.
  • Mirror the normalized field to PostgreSQL through a backward-compatible Prisma migration while MongoDB remains the source of truth.
  • Add tests for casing, trimming/normalization, regex metacharacters, email-like input, empty usernames, collisions, backfill reruns, and legacy values.
  • Document the production migration order and rollback behavior.

Non-goals

  • Searching by email, real name, or hidden identity.
  • Automatically publishing WCA IDs.
  • Adding broad user recommendations.

Dependencies

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: authAuthentication, sessions, identity, and authorizationarea: dataMongoDB, PostgreSQL, migrations, backfills, and data integrityarea: socialFriends, presence, invitations, and notificationsenhancementNew feature or requestpriority: P1High-priority work for the next delivery cycle

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions