rust: `Client::resume_session` errors do not say which stage failed, or whether the session's history could not be loaded

Offen
  • Stimmt etwas nicht?
#2,800 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
api

Rechercherichtung

Start at Client::resume_session and trace the session.resume reply, result decoding, and finish_session_setup calls, including the existing ErrorKind::Session(NotFound) mapping. Compare how each failure is currently surfaced and define verification around distinguishing resume or history-loading errors from post-resume setup failures without matching free-form text.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement
Summary

Client::resume_session returns one Error for every failure along the resume path:

  • the session.resume JSON-RPC reply itself;
  • decoding its result (SessionIdMismatch, JSON);
  • the follow-up setup calls the SDK makes after a successful reply (the MCP auth-interest registration, then finish_session_setup's options update, which disconnects the session when it fails).

Only a reply whose message contains "Session not found" is typed (ErrorKind::Session(NotFound)). Every other failure becomes Error::from_rpc with the CLI's message text.

So a host cannot tell apart:

  1. the CLI refused to load the session's stored history (the transcript exists but could not be restored), where the right response is to stop and tell the user rather than silently start a new, empty session;
  2. a non-history fault on the same reply (authentication, invalid parameters, a concurrent-handle race), which is often transient;
  3. a failure in the SDK's own post-resume setup, after the CLI had already loaded the session.

The only way to separate them today is to match on free-form message text, which is fragile across CLI versions.

Affected versions

github-copilot-sdk (Rust) 1.0.14 and 1.0.15, with Copilot CLI 1.0.85 through 1.0.89.

Observed

Captured with Copilot CLI 1.0.89 and github-copilot-sdk 1.0.15 (paths, ids and the quoted transcript line replaced by placeholders):

  • The stored history cannot be loaded (the session's events.jsonl has an unparseable first record): 
    code=-32603
Request session.resume failed with message: session resume failed: Failed to read JSONL from <path>/events.jsonl: Invalid event at line 1: expected ident at line 1 column 2. Event: <line text>
  • The session has no stored events (an empty events.jsonl): 
    code=-32603
Request session.resume failed with message: Failed to load session events: Session not found: <session-id>

Both come back as the same generic JSON-RPC code, -32603. The SDK types only the second one, ErrorKind::Session(NotFound), because its message contains "Session not found". The first one reaches the host as Error::from_rpc with free-form text. So do non-history faults on the same reply and failures in the SDK's own post-resume calls.

The first message also quotes the offending transcript line verbatim after Event: . A host that logs the error text therefore logs conversation content, unless it strips that text itself. A structured error would avoid the need to parse or scrub it.

Expected

One of the following, in order of preference:

  • (a) The SDK types the stage: for example ErrorKind::Session(ResumeRejected { code, message }) for an error on the session.resume reply, distinct from ErrorKind::Session(SetupFailed { .. }) for the SDK's own post-resume calls.
  • (b) The CLI gives "stored history could not be loaded" its own JSON-RPC error code, or a structured data field such as {"reason": "history_unloadable"}, and the SDK surfaces it as a typed kind, the way it already does for "Session not found".
Why it matters

A host that must never continue a conversation without its prior context has to refuse the turn when history cannot be restored. Without a typed signal, it must either refuse on every resume error, so transient faults read as lost history, or fall back to a fresh session, which silently drops the conversation's context.

Proposed fix
  • The SDK side of (a) is local to Client::resume_session: wrap the session.resume call's error separately from the result decode and from finish_session_setup.
  • (b) needs a CLI-side error code, which the SDK then maps the way it maps "Session not found" today.
Vorherrschende Sprache
Java
Sterne
10.7k
Forks
1.5k
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/copilot-sdk

Alle Issues in github/copilot-sdk

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.