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

Abierto
  • ¿Algo no está bien?
#2,800 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
api

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Java
Estrellas
10.7k
Forks
1.5k
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/copilot-sdk

Todos los issues de github/copilot-sdk

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.