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

feat(provider): exact signed-thinking capture, persistence and replay (incl. Bedrock)

Chiusa
  • Qualcosa non va?
#4,653 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@aheritier ci sta già lavorando.

Dal 19/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

area/providers/anthropic area/providers/bedrock area/sessions

Goal

Capture, persist and replay signed thinking exactly, on all three transports. If the stored state can't be trusted, refuse to continue instead of replaying a rebuilt version.

Why

  • Bedrock flattens reasoning into text + signature fields (adapter.go) and rebuilds the blocks later. It treats a signature without text as redacted content (convert.go), but a signed thinking block can legitimately have empty text. Order between thinking, text and tool calls is also rebuilt rather than preserved.
  • thinkingBindingBehavior picks drop_block automatically when the primary or any fallback checks thinking prefixes (thinking_binding.go). The preserved thinking docs make error the default and describe drop_block as a stopgap that can cost extra output tokens. Switching the default is a deliberate client policy change.
  • The Anthropic client already stores raw response blocks in ProviderState and replays them when they still describe the message (response_content.go). Extend that mechanism; don't create a second one.

Scope

  • Keep blocks in order with their index: thinking (including signed-empty), redacted thinking bytes, text, tool use IDs/inputs and tool results. No "last signature wins".
  • Extend ProviderState additively with a version and the serving model. Unknown versions, incomplete or interrupted streams are never replayed as if they were verified.
  • Bedrock: store and replay native reasoning blocks instead of rebuilding them from flattened fields.
  • Keep the Haiku 5.5 exceptions from #4553 and only those: when thinking is off on Direct/Vertex, omit earlier reasoning from the outgoing request; on Converse, omit it with a warning. Stored history is never modified, and turning thinking back on does not silently re-insert omitted blocks.
  • Make thinking_prefix_mismatch: error the default for 5.x models whose server checks thinking prefixes (moved from #4652). Using drop_block then requires explicit config, keeps logging the dropped paths, and never triggers an automatic retry with thinking removed. Use the native binding control only on the Messages API, where it is documented; don't invent an equivalent for Converse.
  • drop_block, when explicitly configured, never deletes the stored original.

Acceptance criteria

  • Round-trip tests per transport: stream → ProviderState → SQLite and JSON → new runtime → continue an unchanged tool conversation; the replayed request matches the original blocks byte for byte.
  • Signed-empty thinking, redacted thinking and interleaved thinking/text/tool calls survive the round trip.
  • Edited or trimmed history, an imported session and an unknown state version lead to a clear refusal or a documented fallback, never to a silently rebuilt replay.
  • Default error on prefix-checking 5.x models, explicit drop_block with diagnostics, legacy models unchanged. A session using num_history_items trimming either replays exactly or fails with a clear refusal, never a raw 400.
  • Older binaries reading the new state: the limitation is documented (no promise of transparent downgrade).
  • task build, task test, task lint, and go test -race on the touched packages pass.

Parent: #4583 · Depends on #4651

Lingua principale
Go
Stelle
4.6k
Fork
522
Merge medio
10h 33m
PR unite (30g)
231

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna 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 docker/docker-agent

Tutte le issue di docker/docker-agent

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.