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

[Feat]: NoSQL (MongoDB) TaskStore / PushNotificationConfigStore backend — production-verified reference implementation available

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

Los mantenedores suelen responder en 2 días

@ishymko ya está trabajando en esto.

Desde el 28/8/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
fastapi, mongodb
Área
backend, databases

Línea de trabajo

El issue propone añadir un TaskStore y un PushNotificationConfigStore respaldados por MongoDB al SDK a2a-python. Empieza examinando el DatabaseTaskStore existente en el extra a2a-sdk[sql] para comprender la interfaz y la semántica. Revisa la definición proto de Task y la serialización. La implementación debe gestionar la partición por propietario, la paginación con filtros de cursor y los índices TTL para la retención. Sobrescribe get_info_for_dispatch en el almacén de configuración de push usando memoización. Las pruebas deben verificar la persistencia entre réplicas y el comportamiento de la paginación.

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

Descripción

component: server status: needs review

Summary

The SDK currently ships two TaskStore backends: InMemoryTaskStore and the SQLAlchemy-based DatabaseTaskStore (a2a-sdk[sql]). There is no supported path for document/NoSQL databases, even though task records are a natural fit for them. We built and deployed a MongoDB-backed TaskStore + PushNotificationConfigStore for a production A2A server (FastAPI, multi-replica) and would like to propose upstreaming a generic version — either as an optional extra (e.g. a2a-sdk[mongodb]) or as a documented reference implementation.

Why a document store fits this data

  • Tasks are ephemeral, retention-bound records. They are written per request, re-read for a bounded window (GetTask/ListTasks), and then expire. MongoDB TTL indexes handle retention natively (one index on an updated_at field); with SQL backends every deployment has to build its own cleanup job (cron / EVENT scheduler / partition rotation).
  • Many A2A server deployments already run a document store for conversation state, and adding a relational database + Alembic migrations solely for task persistence is a heavy dependency for what is a single-collection workload.

Implementation notes (lessons that may save others time)

We verified these against SDK 1.1.2 semantics; happy to carry them into a PR:

  1. Store the Task as serialized proto bytes, not ProtoJSON. Task.metadata is a proto Struct with arbitrary client-supplied keys — keys containing . or $ become invalid MongoDB document keys after MessageToDict. Storing task.SerializeToString() as opaque bytes (plus a handful of extracted top-level fields for querying: owner, context_id, status.state, status.timestamp) is exact, round-trip safe, and resilient to unknown fields across SDK upgrades.
  2. Owner partitioning parity. All reads/writes are scoped by owner_resolver(context) (default resolve_user_scope), matching InMemoryTaskStore — including refusing cross-owner access on get/delete.
  3. Pagination matching in-memory semantics. Sort (status.timestamp desc — nulls last, id desc); the page token (encode_page_token) is the id of the first item of the requested page (inclusive anchor), so the store re-resolves the anchor document to build a (timestamp, id) cursor filter; unknown tokens raise InvalidParamsError. MongoDB's BSON ordering (Date > Null under descending sort) reproduces the in-memory null-handling exactly.
  4. get_info_for_dispatch must be overridden on custom PushNotificationConfigStore implementations (the base fallback silently drops notifications for authenticated owners — the docstring warns about this, but it is easy to miss). Since streaming turns call it once per emitted event, we front it with a short (5s) in-process memo keyed by task_id, invalidated on set_info/delete_info.

The whole thing is ~200 lines for both stores. Deployed behind a FastAPI JSONRPC server; verified: task survives process restart and is served by a different replica, ListTasks cursor pagination over 100+ tasks, push configs dispatching across replicas.

Questions for maintainers

  1. Is there interest in an official NoSQL backend, and if so, would you prefer an optional extra (a2a-sdk[mongodb], pymongo async client) or a documented recipe in the docs/examples?
  2. If an extra: should it mirror DatabaseTaskStore's constructor conventions (create_table → ensure_indexes, owner_resolver injection), and should retention (TTL) be part of the contract or left to operators?
  3. Would you want the same treatment for PushNotificationConfigStore in the same PR?

If maintainers are open to it, we're happy to submit the PR with tests (the store semantics above are covered by a small in-memory fake collection in our suite; we can port those tests).

Lenguaje dominante
Python
Estrellas
2.2k
Forks
509
Merge medio
3 d 11 h
PR fusionados (30 d)
43

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 a2aproject/a2a-python

Todos los issues de a2aproject/a2a-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.