[Task]: 1.0: Run TCK tests against 1.0 implementation #666

Activity

1. ishymko

   added a parent issue on Feb 3, 2026

   • [Feat]: Upgrade A2A to v1.0 #559
2. ishymko

   added the

   Task

   issue type on Feb 9, 2026
3. ishymko

   removed a parent issue on Mar 17, 2026

   • [Feat]: Upgrade A2A to v1.0 #559
4. ishymko

   added a parent issue on Mar 17, 2026

   • 1.0 Release #701
5. ishymko

   removed a parent issue on Apr 21, 2026

   • 1.0 Release #701
6. Linux2010

   added a commit that references this issue on Aug 2, 2026

   ci: add TCK 1.0 test job to run-tck workflow (a2aproject#666)

   ...

   751f41f
7. kuangmi-bit commented on Aug 6, 2026

   

   kuangmi-bit

   on Aug 6, 2026

   Contributor

   More actions

   Hi — I'd like to pick this up. Quick context on why this is a good fit:

   • We have 3 merged contributions in a2a-tck (style: format code using ruff fix and format #196 CARD-SIGN-003 protected-header structural tests, feat!: Update A2A types from specification 🤖 #197 transport-layer extension activation, plus the eventqueue conformtest package work in a2a-go), so we're familiar with the 1.0 TCK test structure and how to wire a SUT against it.
   • Current state: run-tck.yaml pins TCK_VERSION: 0.3.0.beta3 — still exercising the 0.3 TCK. The 1.0 TCK is available (a2a-tck is at version 1.0.0 on main, tag 1.0.0.alpha2).

   Proposed plan (mirroring the Java SDK's run-tck-1.0-wip.yml):

   1. Bump TCK_VERSION to a 1.0 build and run the JSON-RPC SUT first (smallest surface, already has 0.3 coverage) — fix any compatibility gaps the 1.0 tests surface.
   2. Then enable REST and gRPC rows in the matrix as they go green.
   3. Report per-cell status against the checklist in this issue (Mandatory/Capabilities/Quality/Features × JSON-RPC/REST/gRPC).

   Two questions before I start:

   1. Version pin — use 1.0.0.alpha2, or wait for a final 1.0.0 release? Happy to pin whatever maintainers prefer.
   2. Anyone already working this? The issue has no assignee and no comments, but I want to avoid colliding with in-flight work (e.g. if a branch already has TCK-1.0 wiring).

   I'll start by standing up the 1.0 TCK locally against the JSON-RPC SUT and report what breaks — the first PR can be just the workflow bump plus fixes for the JSON-RPC row.
8. kuangmi-bit commented on Aug 6, 2026

   

   kuangmi-bit

   on Aug 6, 2026

   Contributor

   More actions

   Progress update — I stood up the 1.0 TCK locally against the JSON-RPC SUT and opened #1165 with the two transport-level blockers fixed:

   What was broken (jsonrpc, must level, TCK 1.0.0.alpha2):

   • httpx.post("/") normalizes to a trailing slash → POST /a2a/jsonrpc/ 404'd (route was exact-match only). Fixed in create_jsonrpc_routes (both spellings now route).
   • SUT emitted TaskStatusUpdateEvent without enqueuing the Task first → SDK raises InvalidAgentResponseError (spec [Feat]: get_data_parts as part of utils #311 ordering). Fixed in tck/sut_agent.py.

   Result: 53 failed → 6 failed / 67 passed.

   Remaining 6 (all real, none transport-level):

   1. DM-ART-001 ×4 — SUT returns no artifacts (SUT feature gap; artifact-echo support needed in the SUT or the tests need a capability gate)
   2. TestMessageResponse — SUT replies without artifact/structured payload variants
   3. JSONRPC-SSE-002 — ContentTypeNotSupportedError (-32005) reported as ParseError (-32700) — SDK error-code mapping gap

   Still to do (proposing as follow-up PRs):

   • REST and gRPC rows in the matrix (workflow currently runs jsonrpc only — see run-tck.yaml)
   • Bump TCK_VERSION from 0.3.0.beta3 to a 1.0 build + update the run_tck.py CLI invocation (--category/--transports → --level/--transport)

   Questions from my earlier comment still stand (version pin, collision check) — happy to take the workflow bump + REST/gRPC rows next once #1165 is reviewed, or to hand off cleanly if anyone else is already on it.
9. kuangmi-bit commented on Aug 6, 2026

   

   kuangmi-bit

   on Aug 6, 2026

   Contributor

   More actions

   Extended the local run to all three transports (TCK 1.0.0.alpha2, must level, same SUT). Two more SUT compatibility fixes were needed and are now pushed to #1165:

   • protocolBinding: 'REST' → 'HTTP+JSON' — the 1.0 binding map only recognizes JSONRPC/GRPC/HTTP+JSON; the old name made the REST row untestable
   • gRPC interface url http://localhost:50051 → localhost:50051 — grpcio treats the url as a channel target

   Current per-transport status (must level):

   Transport	Passed	Failed	Remaining failures
   jsonrpc	67	6	5× SUT artifacts/MessageResponse gaps + 1× content-type error code
   http_json (REST)	61	5	5× SUT artifacts/MessageResponse gaps
   grpc	48	7	5× SUT artifacts/MessageResponse gaps + 2× gRPC status codes

   So all three transports are wired and exercising the 1.0 TCK; the remaining failures are (a) SUT feature gaps — the SUT never produces artifact-carrying or message-variant responses (DM-ART-001 etc.), and (b) two error/status code mappings. Happy to take the workflow bump (TCK_VERSION → 1.0 build, run_tck.py CLI: --category/--transports → --level/--transport) as the next PR once #1165 is in, or to fix the SUT artifact gaps — whichever maintainers prefer.
10. Linux2010

    added a commit that references this issue on Aug 14, 2026

    ci: add TCK 1.0 test job to run-tck workflow (a2aproject#666)

    ...

    43484c5
11. mykytanetipa

    added a commit that references this issue on Sep 10, 2026

    fix(tck): enqueue Task before TaskStatusUpdateEvent in SUT agent (#1165)

    ...

    3971c70
12. astrogilda commented on Oct 2, 2026

    

    astrogilda

    on Oct 2, 2026

    Contributor

    More actions

    okay... the reader and CI action are ready to wire in: probityai/agent-evidence-observer#23.

    The six-case native JSON-RPC packet uses SDK 1.2.1 and retains the original requests, responses and every declared attempt, including errors, a timeout and an absent launch. A separate consumer selects the source/native/common pins and recomputes the result. Changed history or sources fail the gate.

    let's put this beside the 1.0 TCK work. It's a finite result-integrity check; normative TCK coverage and REST/gRPC remain separate. The first integration should have one workflow owner, retain the raw packet, and block result publication when the reader refuses. Who owns that workflow?