@supabase/middleware - v0.6.0
    Preparing search index...

    Type Alias Conflict<Key>

    Conflict: `middleware-conflict: key '${Key}' is already present on the upstream context`

    Sentinel type used to surface a key collision with the upstream context as a TypeScript error at the call site. Both composition paths put it in the handler parameter position — pipeline via ValidateEntries, nesting via NoConflict — because that is the position TypeScript prints:

    Argument of type '(req, ctx) => …' is not assignable to parameter of type
    "middleware-conflict: key 'alpha' is already present on the upstream context"

    The alternative siting — the sentinel in a failed Base constraint — is substituted silently. The stack still fails to compile either way, but on that path the reported error is an overload mismatch on the enclosing call, in which the inner handler's ctx has collapsed to never (printed as ctx?: undefined); the collision is never named, and the colliding key may not appear at all. Keep the sentinel on a parameter.

    The two paths differ only in how much surrounds the message, and that is decided by how many signatures at the call site can take a handler. One handler-taking signature (pipeline, or a hand-written signature with a single handler form) reports a one-line TS2345 with the sentinel on that line. Two or more (Middleware, whose cascade and propagation forms both take a handler) reports TS2769, with the sentinel inside the indented per-overload breakdown. A test that checks a collision should match the sentinel text rather than the code, and fold continuation lines when it parses tsc output.

    Type Parameters

    • Key extends string