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

Add post-payment delivery validation without retrying possible spend

Abierto
  • ¿Algo no está bien?
#651 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend-api-design, payments

Línea de trabajo

Comienza con el flujo de pagos de AgentCore LangGraph en src/bedrock_agentcore/payments/integrations/langgraph/README.md y sigue los tres puntos de entrada nombrados: wrap_tool_call, awrap_tool_call y Strands after_tool_call. Reproduce el flujo simulado de PaymentManager con un challenge, una credencial, un reintento pagado y una salida malformada. Se considera terminado cuando el callback opcional comparte una semántica coherente, conserva la evidencia de un posible gasto al rechazar, evita otro intento de pago automático y deja sin cambios el comportamiento cuando no hay callback.

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

Descripción

enhancement

Is your feature request related to a problem? Please describe.

The AgentCore Payments LangGraph middleware and Strands plugin can detect a
payment challenge, obtain a credential, retry the tool, and return the paid
result. There is no opt-in application-output gate between that paid retry and
result promotion.

That leaves a buyer unable to reject malformed or contract-invalid application
output while preserving two facts: a payment credential may already have spent,
and the middleware must not automatically pay or retry again.

A credential-free reproduction uses a fake PaymentManager and a local tool:

  1. The first tool call returns an x402 or MPP payment challenge.
  2. The fake manager returns one payment credential.
  3. The paid retry returns HTTP 200 with malformed application output.
  4. The current middleware returns that output through LangGraph sync,
    LangGraph async, or Strands without a buyer-owned validation hook.

No AWS account, wallet, signature, or live payment is needed to reproduce the
control-flow gap.

Describe the solution you'd like

Add an optional post-payment delivery callback to the existing integrations.
When configured, it should:

  • receive the raw paid result plus an immutable snapshot of the selected
    payment requirement or challenge;
  • run after exactly one credential generation and one paid retry;
  • preserve the original paid result and explicit possible-spend evidence when
    validation rejects or raises;
  • return a deterministic failure through the native LangGraph or Strands path;
  • set native retry behavior so the same result cannot trigger another automatic
    payment attempt; and
  • leave current behavior unchanged when the callback is absent.

Protocol-native evidence should retain its authority label. An x402 Payment
Response or MPP Receipt can be exposed as observed, unverified evidence. Calling
settlement verified should require a separate protocol-specific verifier that
reconciles the native transaction or reference against the frozen payment
terms.

The three public integration paths should share the same semantics:

  • LangGraph wrap_tool_call
  • LangGraph awrap_tool_call
  • Strands after_tool_call

Describe alternatives you've considered

  • Tool-specific wrappers duplicate payment middleware and can lose the selected
    challenge and possible-spend context.
  • LLM inspection after the result returns is not a fail-closed output contract.
  • Requiring a seller to echo protocol, network, scheme, challenge or offer ID,
    amount, asset, payee, credential digest, and transaction in one custom bag is
    not portable. Standard x402 settlement responses and MPP receipts do not echo
    that complete set, and seller-authored echoes are not independent settlement
    verification.

Additional context

Current source references:

The repository's current contribution policy asks external users to report
problems and request features rather than submit code pull requests, so this is
intentionally a feature request without an external patch.

Lenguaje dominante
Python
Estrellas
776
Forks
153
Merge medio
1 d 8 h
PR fusionados (30 d)
15

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 aws/bedrock-agentcore-sdk-python

Todos los issues de aws/bedrock-agentcore-sdk-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.