Skip to content

Avoid stale full-object Customer metadata writes #179

Description

@kilbot

Identified during adversarial review of refactor/customer-profile-metadata.

Problem

Customer metadata writes currently send a full metadata object built from a previously-read Customer snapshot. This pattern exists in profile, OAuth provider sync, and Discord link/unlink metadata writes.

If two metadata-writing requests race, the later write can restore stale unrelated keys and silently drop the other write. Example: profile billing metadata save racing with Discord link/unlink or OAuth provider metadata sync.

Why it matters

Silent loss of account_profile, auth-provider attribution, or Discord link metadata can break receipts, profile display, connection state, or role sync without surfacing a conflict to the Customer.

Suggested approach

Investigate a narrow Customer metadata write seam that either:

  • uses a backend/Medusa operation that atomically patches a metadata sub-key, or
  • re-fetches and retries with conflict detection (updated_at/ETag/version) before replacing full metadata.

Avoid turning this into a broad Customer DAL/auth helper; ADR-0003 rejected generic auth helpers because unauthenticated behavior intentionally differs by surface.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions