Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#1,210 2 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@ishymko is already working on this.

Since Aug 28, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
fastapi, mongodb
Domain
backend, databases

Research direction

The issue proposes adding a MongoDB-backed TaskStore and PushNotificationConfigStore to the a2a-python SDK. Start by examining the existing DatabaseTaskStore in the a2a-sdk[sql] extra to understand the interface and semantics. Review the Task proto definition and serialization. The implementation must handle owner partitioning, pagination with cursor filters, and TTL indexes for retention. Override get_info_for_dispatch in the push config store with memoization. Tests should verify cross-replica persistence and pagination behavior.

Written by the indexing model from the issue text.

Description

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).

Dominant language
Python
Stars
2.2k
Forks
499
Avg merge
3d 10h
Merged PRs (30d)
26

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from a2aproject/a2a-python

All issues in a2aproject/a2a-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.