Skip to content

Reproduce summary-only Issues disconnect-handling concern from PR #55 #58

Description

@mchwang

Copilot's third review summary on #55 (no inline finding) says "a moderate unresolved disconnect-handling issue remains in web/server.ts".

Candidate failure case: the /api/issues handler attaches res.once('close', depart) only after it has read and parsed the body. If the client's connection closes before that listener is attached, close has already fired. The handler would then wait for the whole shared refresh (up to the 12 s gateway timeout) instead of leaving at once.

Attempt on validated head 34b9292: a client sent the full body and destroyed the socket in the same write. In 3 of 3 runs the handler still received close after attaching the listener and left correctly. The fixture could not assert the listener-before-close ordering, so under AGENTS.md ("assert the disputed intermediate representation") this does not prove or disprove the concern.

To close this issue: force the ordering deterministically (for example, delay listener attachment through an injected hook, or destroy the socket from a request event on the server) and assert that close fired before the handler waited. If that reproduces, check res.closed or res.destroyed right after attaching the listener, with a failing-before/passing-after regression. If it cannot happen, record why and close.

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