Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Cold resume can replay undecryptable encrypted reasoning without a safe fallback

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

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java

Direzione di ricerca

Inizia dai percorsi di runtime responsabili della serializzazione del replay, dello stato del turno in sospeso e dell’ordine degli effetti collaterali, usando la riproduzione con il fixture del provider deterministico descritta nell’issue. Il lavoro è completo quando un errore strutturato di decrypt/parse può attivare un retry atomico prima dell’effetto collaterale senza duplicare l’evento dell’utente, mentre le riprese successive evitano il prefisso invalidato e gli errori non correlati o ripetuti rimangono terminali.

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

Descrizione

bug enhancement

Summary

When a cold-resumed session preserves prior reasoning fields, the first model request can fail with HTTP 400 if the provider can no longer validate the replayed encrypted_content:

Encrypted content ... could not be decrypted or parsed.

The logical model identifier can remain unchanged while the provider's underlying deployment or encryption domain changes. The SDK currently treats this as a terminal session error. Consumers cannot atomically remove the incompatible pre-resume reasoning, retry the pending turn, and prevent the same payload from being replayed on later resumes.

This leaves consumers with two unsafe choices:

  1. Strip reasoning on every resume, losing reasoning continuity and prefix-cache reuse.
  2. Preserve reasoning on every resume, leaving the session unrecoverable when a previously valid blob becomes unverifiable.

This is related to #615, which correctly preserved encrypted_content for stateless multi-turn requests. Preservation should remain the normal path, with a bounded recovery path for blobs that a provider can no longer verify.

Versions and configuration

  • Reproduced with the resume behavior in @github/copilot CLI 1.0.78.
  • The same relevant behavior is present in CLI 1.0.73.
  • Prior reasoning is preserved on resume by setting COPILOT_STRIP_REASONING_ON_RESUME=false.
  • The provider uses a stable logical model name but may route requests across compatible model deployments.

Reproduction

A provider fixture can reproduce the failure deterministically:

  1. Create a session with a reasoning model.
  2. Complete a turn whose assistant reasoning contains encrypted_content.
  3. Disconnect and cold-resume the session with reasoning preservation enabled.
  4. Send the next user message.
  5. Have the provider reject the replayed blob with HTTP 400 and the decrypt/parse error above.

Actual behavior

The resumed turn fails terminally. A generic consumer retry reuses the same incompatible history. The public SDK API does not provide an atomic way to sanitize the resumed prefix without risking a duplicate user event or repeated tool side effects.

Expected behavior

The SDK should preserve reasoning by default, but recover safely when the first post-resume call proves that prior encrypted reasoning is incompatible.

One possible design is a resume policy such as preserveWithStripFallback:

  1. Match only the structured HTTP 400 decrypt/parse failure, not every encrypted-content or invalid-request error.
  2. Recover only before assistant output or tool execution has started.
  3. Atomically strip incompatible pre-resume opaque reasoning and retry the same pending turn once.
  4. Do not append the user event twice.
  5. Persist an invalidation cutoff or generation so later resumes do not replay the poisoned prefix.
  6. Continue preserving reasoning generated after recovery.
  7. If available, use an opaque provider-issued verification-domain identity to avoid replay proactively when compatibility does not match.

Unrelated errors, failures after side effects, and a failed recovery attempt should remain terminal. The retry must never loop.

Why this belongs in the runtime

The runtime owns replay serialization, pending-turn state, and side-effect ordering. Handling this outside the SDK cannot reliably distinguish a safe first-call recovery point or rewrite session history atomically.

This recovery keeps the cache and multi-turn reasoning benefit for healthy resumes. Only a session with incompatible ciphertext loses its old hidden-reasoning prefix once, after which newly generated reasoning can be preserved normally.

Lingua principale
Java
Stelle
10.5k
Fork
1.5k
Merge medio
1g 9h
PR unite (30g)
130

Guida per i contributori

Apri la guida per i contributori

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.