post_generate_fixes.py matches exact base-class lists and breaks when envelope composition changes #1680

Activity

1. KonstantinMirin commented on Oct 28, 2026

   

   KonstantinMirin

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   A second failure on adcontextprotocol/adcp#8547's current head (43c537b522), separate from the post_generate_fixes.py signatures. "Generate Python SDK" now fails earlier, in generation:

   $ref file not found: <workdir>/sdk/.typegen-*/.schema_temp/core/async_response_refs/core/context.json
   

   The generator copies the async response schemas into core/async_response_refs/ and then resolves their $refs relative to that copy. Since #8547 those schemas reference core schemas directly (/schemas/core/protocol-envelope.json, /schemas/core/task-submitted.json, /schemas/core/task-id.json, /schemas/core/context.json), so the copied tree has to keep resolving them from the schema root.
2. KonstantinMirin commented on Oct 28, 2026

   

   KonstantinMirin

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   To be clear about where the problem lies: the schemas aren't wrong now. They were wrong before.

   The old task response schemas didn't compose the envelope consistently, closed some roots, and copied envelope fields by hand. Generated code built from them couldn't represent a conforming response, so the generators grew patches to compensate:

   • post-processors written for one specific schema (postProcessCompactTaskSubmittedEnvelope);
   • rewrites keyed on exact class signatures (post_generate_fixes.py, 29 of them);
   • a copied side tree for the async schemas, with its own $ref resolution;
   • stripping or relaxing fields at runtime.

   adcontextprotocol/adcp#8547 fixes the schemas: plain allOf composition of protocol-envelope, one definition per envelope field (core/task-id.json, core/task-submitted.json, …), and open response roots. With that in place, these patches aren't needed. They fail because they're aimed at a schema layout that no longer exists.

   So the fix on the SDK side is to remove them, not to adapt them to the new layout. A generator that maps schema to classes directly through standard allOf, $ref and discriminated oneOf produces the right types from these schemas without them. Post-processing that works around a general generator limitation, the same way for every schema, is fine. Post-processing that has to know the structure of one particular schema is the sign of a problem in the schema, and that problem should be fixed in the schema.
3. bokelley

   added a commit that references this issue on Oct 29, 2026

   fix(codegen): find generated classes by name, and derive emitted enve…

   ...

   50fe9e8
4. KonstantinMirin commented on Oct 30, 2026

   

   KonstantinMirin

   on Oct 30, 2026

   CollaboratorAuthor

   More actions

   #1705 fixed the class-signature matching, but "Generate Python SDK" on adcontextprotocol/adcp#8547 (38c5e7a6e9) still fails on the second issue in this thread:

   $ref file not found: <workdir>/sdk/.typegen-*/.schema_temp/core/async_response_refs/core/context.json
   

   The cause is the side tree in scripts/generate_types.py around line 783 (and consolidate_exports.py:231). The generator copies the async response schemas into core/async_response_refs/ and rewrites their relative $refs by hand. Since #8547, those schemas reference core schemas directly (protocol-envelope, task-submitted, task-working, task-input-required, task-id, task-message, context), and a reference rewritten relative to the copy resolves to core/async_response_refs/core/…, which doesn't exist. The readiness check on #1678 overlaid bundle-style refs, so it took a different path and didn't hit this.

   Same request as before: drop the copied side tree and resolve $refs from the schema root. The schemas use plain root-relative /schemas/... references and standard allOf, so the generator doesn't need to relocate or rewrite them.
5. bokelley

   added a commit that references this issue on Oct 30, 2026

   fix(codegen): generate the composed envelope layout of adcp#8547 (#1741)

   ...

   9a3bc5f
6. bokelley commented on Oct 31, 2026

   

   bokelley

   on Oct 31, 2026 – with conductor.build App

   Contributor

   More actions

   Status for this issue, on next (the pre-release line), shipped in 10.0.0-beta.5 (v10.0.0-beta.5).

   Fixed, and verified against the real 3.3.0-beta.3 bundle (the first published one that composes the envelope):

   • The class-signature failure (fix(codegen): find generated classes by name, and derive emitted envelope bases from the bundle #1705) and the $ref file not found: …/core/async_response_refs/core/context.json failure (fix(codegen): generate the composed envelope layout of adcp#8547 #1741: core refs are named by their absolute temp-tree path; the generator runs --allof-class-hierarchy always and pins the properties a composing schema narrows) are both on next. Regenerating from beta.3 runs to completion and make validate-generated is clean.
   • Generated responses derive from ProtocolEnvelope (no separate AdcpVersionEnvelope base) and carry status, task_id, timestamp, adcp_version, adcp_major_version, replayed, … The task-message lattice residue pins (responses that composed neither envelope) are now empty and kept as assertions. This also answers Generated response types can't represent the protocol envelope #1678.
   • Version gating (matches adcp-client#3493): status is required on 3.3 responses, including list_products and decline_proposals. Under 3.2.x those have none, so a 3.2.x seller neither requires nor emits it. The served release's own response schema decides (fix(compat): decide the compact response status from the served release's schema #1761), not its version string: 3.3 → 3.2 conversion drops status as a recorded loss, 3.2 → 3.3 supplies it, and a typed model's defaulted completed is not sent to a closed 3.2 root. A 3.2.x backport that composes the envelope flips the answer with no SDK change.

   Not done, on purpose of scope: the cleanup the issue asks for is still open. The copied core/async_response_refs/ side tree is still generated (it now resolves, but it is still a side tree), consolidate_exports.py still knows about it, and the class-keyed rewrites in post_generate_fixes.py remain. One of those, restore_response_variant_aliases, re-renders 22 response modules from raw schema JSON, and I found it recognised a submitted arm only by a local status const, which #8547 moved into core/task-submitted.json; next keeps the fields typed correctly (status pinned to submitted, task_id required) but that emitter is exactly the kind of schema-shaped patch the issue wants removed. I'd keep this issue open for that removal.

   🤖 Generated with Claude Code