Skip to content

bug(cursor): discarded OAuth poll responses can block the next request #571

Description

@ooiuuii

Problem

Cursor OAuth polling discards HTTP 404 and other non-success responses without consuming or cancelling their bodies. A discarded response can occupy a pooled connection and prevent the next poll from running promptly.

Path: /login cursor -> loginCursor() -> pollCursorAuth() -> fetchWithTimeout(). HTTP 404 is the normal browser-handoff pending branch.

Reproduction

On main f6b49ae59605b1276b8267f2886d22c03f01533c, a real loopback HTTP server sends a valid 404 with a 448 KiB body, then a valid synthetic token response. With a single-connection Undici pool, the unmodified poller issues only the first request and is cancelled by the fixture's 2-second deadline. Cancelling the discarded body permits request two and successful completion (about 155 ms locally).

This uses no real account or provider request. Node 22.22.3 / Undici 8.9.0. The fixture restores the dispatcher and closes the pool/server.

Expected / boundaries

Release discarded non-success bodies before retrying or failing, as required by Undici's response-body lifecycle guidance. Keep retry counts, backoff, timeout and token parsing unchanged.

The existing 30-second request abort bounds retention: this is not a permanent leak or a claim that every login fails. A narrow cleanup fix has 3/3 focused and 88/88 provider tests passing.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions