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

Aperta
#2,800 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
api

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Java
Stelle
10.7k
Fork
1.5k
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di github/copilot-sdk

Tutte le issue di github/copilot-sdk

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.