Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,653 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@aheritier ya está trabajando en esto.

Desde el 19/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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

Lenguaje dominante
Go
Estrellas
4.6k
Forks
522
Merge medio
8 h 20 min
PR fusionados (30 d)
219

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 docker/docker-agent

Todos los issues de docker/docker-agent

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.