Feedback (v2.0 / 0f544a5): product ID resolution 404, silent empty placements on POST /packages, and growing package counts

[jaanijuk]

Summary

Field feedback from hands-on testing of the seller-agent reference implementation (tag v2.0 · SHA 0f544a5) while working on drafting a runbook here in Australia to potentially support a local pilot. The SDK is in good shape overall (boot, catalogue, API-key lifecycle, partial-patch updates and the event bus all worked first time). Three reproducible observations are reported below, plus a note on tagging.

Happy to share full logs, retest on a candidate fix or newer tag, and feed learnings back as needed.

Environment

seller-agent: tag v2.0 · SHA 0f544a5  (see tagging note — local checkout of this SHA
              may not match the running process)
host:         WSL2 Ubuntu 24.04 (Windows 11), Python 3.12.3, venv install (pip install -e .)
config:       AD_SERVER_TYPE=csv, CSV_DATA_DIR=./data/csv/samples/aws_workshop
run:          uvicorn ad_seller.interfaces.api.main:app --port 8001

Observation 1: product IDs from /products don't resolve on /products/{id}

A product ID read from GET /products returns 404 Not Found on an immediate GET /products/{id} lookup.

ID=$(curl -s localhost:8001/products | python3 -c "import json,sys; print(json.load(sys.stdin)['products'][0]['product_id'])")
curl -s -o /dev/null -w "%{http_code}\n" localhost:8001/products/$ID
# observed: 404

This behaviour is puzzling against the source on this tag: both handlers read from _get_static_product_catalog(), whose docstring states IDs are "generated once and cached," so a list-then-lookup should hit the same cache and succeed. Separately, repeated ProductSetupFlow execution blocks appeared in the server log (each ending Created 4 mock synced packages) around catalogue activity even though list_products is documented to read the static cache instead of running the flow (to avoid an OpenDirect MCP session.initialize() hang). The observed flow runs may be triggered by a different endpoint in the session.

I cannot reconcile the observed 404s with the static-cache design, so this is reported as-observed. It may indicate a regeneration / caching path not visible in the read handlers, or a divergence between the checked-out SHA and the running process.

Server log excerpt (trimmed):

Starting Flow Execution — Name: ProductSetupFlow
INFO  Created 4 mock synced packages          product_setup_flow.py:277
INFO: 127.0.0.1 - "GET /products HTTP/1.1" 200 OK
...
INFO: 127.0.0.1 - "GET /products/prod-47d04b2e HTTP/1.1" 404 Not Found

Observation 2: curated-package creation silently produces empty placements (cause confirmed in source)

POST /packages with product_ids taken from /products returns 200, emits PACKAGE_CREATED, but the created package has placements: [] — products are not attached and no error or warning is returned.

# take two IDs from /products, then immediately:
curl -s -X POST localhost:8001/packages -H "Content-Type: application/json" \
  -d '{"name":"Test Bundle","product_ids":["<id1>","<id2>"],"base_price":38.0,"floor_price":30.0}' \
  | python3 -c "import json,sys; p=json.load(sys.stdin); print(p['package_id'], 'placements:', len(p.get('placements',[])))"
# observed: pkg-... placements: 0   (HTTP 200, PACKAGE_CREATED emitted)

Root cause is visible in the source. create_package builds placements by calling storage.get_product(pid) for each id and only appends when the lookup returns data. However, /products serves from the in-memory _get_static_product_catalog(), which is a different data store from storage. Product IDs surfaced by /products are therefore absent from storage, every get_product misses, and placements are silently skipped.

(POST /packages/assemble correctly raises 400 "No valid products found for assembly" in the equivalent case; the primary POST /packages path surfaces nothing.)

Suggested fixes:

• (a) Reconcile the read catalogue with storage so /products IDs are resolvable by create_package; and/or
• (b) Have create_package return 400/422 (or at least a warning field) when none of the supplied product_ids resolve, matching the behaviour of assemble.

Observation 3: package/media-kit counts grow across repeated reads

Counts climb with repeated catalogue reads. After creating one package and featuring one other, GET /media-kit reported total_packages: 13, featured_count: 8 which is well above what was curated. This is consistent with the mock packages being re-seeded during the session (the repeated Created 4 mock synced packages lines noted above), though the exact trigger has not been confirmed in source.

for i in 1 2 3; do curl -s localhost:8001/products > /dev/null; done
curl -s localhost:8001/packages | python3 -c "import json,sys; print('packages:', len(json.load(sys.stdin)['packages']))"

Note on tagging: v2.0 appears to have moved

A checkout of v2.0 on ~17 July resolved to seller a8b4eff / buyer 846acba; a fresh clone on 22 July resolved v2.0 to 0f544a5 / cc9c4d7. Separately, the local checkout of 0f544a5 has a /products implementation (static cache, IDs cached once) that does not match the runtime behaviour observed, which raises the possibility that the running server and the checked-out commit are not identical.

Since participants are being advised to pin to release tags for reproducibility, immutable or point-versioned tags (v2.0.1, etc.) would help considerably.

What worked well

CSV-mode boot, /health, the A2A agent card at /.well-known/agent.json, the 12-product workshop catalogue with correct AdCOM/taxonomy fields, buyer API-key minting via POST /auth/api-keys (shown-once design + usage tracking), partial-patch PUT /packages/{id} (emits PACKAGE_UPDATED), and the event bus persisting events with UUIDs all behaved exactly as documented. The two-layer /packages (operator CRUD) vs /media-kit (buyer read-only) split is a genuinely teachable illustration of the standard.

[atc964]

Hi @jaanijuk — thank you for a well-put-together report; the curl transcripts and the tagging note made this straightforward to run down, and your instinct that "the running process and the checked-out commit are not identical" turned out to be the key to the whole thing.

The unifying finding: the v2.0 tag currently resolves to a commit from mid-April (0f544a5), roughly three months older than the code you had checked out on ~17 July (a8b4eff). Your runtime observations all match the April code; the static-cache /products source you quoted is from the July code. Both were real — they were just different SHAs wearing the same tag.

On your three observations, tested against current main (v2.2.0):

1. Product ID 404s — at 0f544a5, both /products and /products/{id} run ProductSetupFlow per request, minting fresh random prod-… IDs each time, so the lookup can never hit — and each run also logs the "Created 4 mock synced packages" lines you saw. This is fixed at v2.2.0 (single cached catalog; list-then-lookup verified returning 200 with stable IDs).

2. Silent empty placements — your root-cause analysis is exactly right, and this one is still present at v2.2.0: create_package resolves product_ids against storage, while /products serves the in-memory catalog that is never persisted there, so every lookup misses and is silently skipped (/packages/assemble hits the same mismatch but correctly 400s). We're taking both of your suggested fixes: catalog-aware resolution in create_package, plus a 422 when zero IDs resolve and a warning field for partial resolution.

3. Growing counts — confirmed: flow-seeded packages get fresh random pkg-… IDs on every run, so seeding is not idempotent. At 0f544a5 this fired on ordinary catalogue reads (hence your 13/8); at v2.2.0 the only trigger is an explicit POST /packages/sync, but repeated syncs still duplicate the synced layer, which we'll fix with deterministic IDs / replace-on-sync.

4. Tagging — you're right that v2.0 did not stay put, and we take this seriously. We're moving to immutable tags and point releases (v2.0.1-style corrections), with an errata note on the v2.0 release. Apologies for the hours this cost you.

For your runbook, we'd suggest pinning v2.2.0 (1ad14f9), which fixes observation 1 and the passive-read version of observation 3; we'll follow up here when the placements fix lands in a point release you can retest against. And thank you for the "what worked well" section — genuinely useful signal on what to keep stable for the pilot.

[atc964]

@jaanijuk — the placements fix is live: v2.2.1 is out with both fixes from this thread.

• POST /packages now resolves product_ids against the catalog (your fix (a)), returns 422 with the unresolved ids when nothing resolves, and reports unresolved_ids + a warning on partial resolution (your fix (b)) — assemble behaves consistently.
• POST /packages/sync is now idempotent: deterministic package IDs, upsert on re-sync, stale synced packages pruned — repeated syncs converge, and curated packages are untouched.

For your runbook: pin v2.2.1. Your exact curl sequences from this report were used as the verification cases — list-then-lookup returns 200, package creation attaches placements, and double-sync holds counts stable. Happy to look at any retest results.

[jaanijuk]

Update: An additional datapoint from the transaction path on 0f544a5

One more observation that extends this beyond package placements. (Still on 0f544a5 as my baseline and I'll rerun everything on v2.2.1 as soon as I have it installed locally.)

POST /proposals fails when given a product_id that was just returned by /products:

product_id: prod-f04a95ed
POST /proposals →
{
  "proposal_id": "prop-ac048119",
  "recommendation": "",
  "status": "failed",
  "counter_terms": null,
  "approval_id": null,
  "errors": []
}

As a control, the identical call with a deliberately invalid ID gave the same response:

product_id: "prod-does-not-exist" →
{
  "proposal_id": "prop-066ce4f7",
  "recommendation": "",
  "status": "failed",
  "counter_terms": null,
  "approval_id": null,
  "errors": []
}

The caller therefore cannot distinguish a valid but unresolvable ID from outright garbage as errors is empty in both cases. The server log shows ProposalHandlingFlow running every method to completion (receive_proposal, validate_product, validate_audience, evaluate_pricing, check_availability, run_crew_evaluation, identify_upsell, generate_counter_terms, execute_decision) followed by Flow Execution Completed and 200 OK. Nothing raises; the flow simply resolves to failed with no detail.

Possible link to the earlier observations: submit_proposal appears to re-run the product flow and validate against its output:

setup_flow = ProductSetupFlow()
await setup_flow.kickoff_async()
...
result = flow.handle_proposal(..., products=setup_flow.state.products)

Hence validation happens against a freshly regenerated product list rather than the catalogue the client read from. (On a less-populated database the same call previously returned errors: ["Product not found: <id>"], which is consistent with that reading, but I can't confirm it's the cause of the empty-errors case above).

Practical impact: NegotiationClient.auto_negotiate() requires an existing proposal (it POSTs to /proposals/{proposal_id}/counter), so proposal creation failing blocks the buyer-side negotiation scenarios entirely on this build. The transaction chain proposals → negotiation → deals is affected, not just curated packages.

Suggestions:

1. Check whether submit_proposal should validate against the same catalogue source the read endpoints serve.
2. Populate errors whenever status is failed, so the failure is self-diagnosable.

Keen to add "create a proposal from a /products ID → auto-negotiate against it" to my v2.2.1 retest (once the iab-agentic-primitives dependency is publicly installable) and will report back here.