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

[azure-ai-agentserver-responses] Failed response inputs are replayed in conversation history

Abierto
  • ¿Algo no está bien?
#48,929 1 comentario 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

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
azure, python
Área
api, backend, cloud

Línea de trabajo

Comienza con ResponseProviderProtocol y get_history_item_ids(), y luego sigue cómo los proveedores in-memory, de archivo y Foundry construyen el historial de conversaciones y de respuestas anteriores. Reproduce los casos de conversaciones fallidas y respuestas independientes, incluidos los modos de streaming y background. Se considera terminado cuando las entradas fallidas siguen disponibles mediante /responses/{id}/input_items, pero se excluyen del historial que se puede reproducir, mientras que el historial correcto permanece sin cambios.

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

Descripción

Hosted Agents Service Attention
  • Package Name: azure-ai-agentserver-responses
  • Package Version: 2.2.0b2 on current main; originally observed through agent-framework-foundry-hosting 1.0.0b260730
  • Operating System: Cross-platform; reproduced with a hosted Foundry agent and locally
  • Python Version: 3.13.14 in the original report

Describe the bug

AgentServer persists a stored response and its input_items when it processes the initial response.created / in_progress event. If the handler later emits response.failed, update_response() updates the response envelope but does not change the stored input references.

get_history_item_ids() subsequently includes those input IDs:

  • when resolving responses in a conversation_id; and
  • when a failed standalone response is later chained through previous_response_id.

As a result, invalid input that caused one request to fail is replayed into subsequent otherwise-valid requests, potentially poisoning the conversation indefinitely.

Original report and reproduction: https://github.com/microsoft/agent-framework/issues/7630

Agent Framework workaround under review: https://github.com/microsoft/agent-framework/pull/7637

That workaround has to buffer synchronous handler events so it knows the terminal status before AgentServer performs its initial create, and it wraps/mutates AgentServer's private providers. It cannot address streaming and background failures cleanly without delaying their streams.

To reproduce

  1. Create a conversation.
  2. Submit a response containing an unmatched function_call_output:
response = client.responses.create(
    conversation=conversation.id,
    input=[
        {"role": "user", "content": "Hello"},
        {
            "type": "function_call_output",
            "call_id": "call_that_does_not_exist",
            "output": "invalid output",
        },
    ],
)
  1. Confirm the response fails because no matching function call exists.
  2. Submit a valid request to the same conversation:
response2 = client.responses.create(
    conversation=conversation.id,
    input="Hello, how are you?",
)
  1. Observe that the second request fails with the same unmatched-function-call error because the first request's input was included in resolved conversation history.

The equivalent issue occurs if step 2 creates a stored standalone failed response and step 4 uses previous_response_id=response.id.

Actual behavior

get_history_item_ids() includes the failed response's own input IDs, so subsequent handlers receive and replay the invalid input.

Expected behavior

Failed-response inputs should remain stored and retrievable through /responses/{id}/input_items for diagnostics, but should not be returned as replayable history for either conversation_id or previous_response_id. Successful-response history should remain unchanged.

Ownership rationale

This behavior is defined by azure-ai-agentserver-responses:

  • its orchestrator decides when response inputs are persisted;
  • ResponseProviderProtocol defines create, update, and history operations;
  • its in-memory and file providers build conversation and previous-response history; and
  • its Foundry provider delegates to the hosted history/item_ids storage endpoint.

Fixing this only in Agent Framework's foundry_hosting adapter leaves other AgentServer hosts and streaming/background request modes with the same behavior.

Suggested direction

Define and enforce a provider invariant that a failed response's own input_item_ids are excluded from replayable history while the stored items remain available for diagnostic retrieval.

  • Apply this before history-limit truncation.
  • Update the in-memory and file providers.
  • Apply the same behavior in the Foundry history/item_ids backend, or expose a supported server-side filter.
  • Add tests for failed conversation turns and failed standalone responses later chained with previous_response_id, across synchronous, streaming, and background modes.

Related:

Lenguaje dominante
Python
Estrellas
5.6k
Forks
3.4k
Merge medio
1 d 18 h
PR fusionados (30 d)
202

Preparar el entorno

Abrir en Codespaces

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

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 Azure/azure-sdk-for-python

Todos los issues de Azure/azure-sdk-for-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.