# Json\_schema sampling call fails with empty {success:false,error:""} on Cloud Agent despite onUnsupported=json\_object set

**URL:** <https://forum.anna.partners/t/json-schema-sampling-call-fails-with-empty-success-false-error-on-cloud-agent-despite-onunsupported-json-object-set/250>\
**Category:** Developers\
**Created:** [August 21, 2026, 2:57am UTC](https://forum.anna.partners/t/json-schema-sampling-call-fails-with-empty-success-false-error-on-cloud-agent-despite-onunsupported-json-object-set/250 "2026-08-21T02:57:58Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Calder](https://yyz1.discourse-cdn.com/flex033/user_avatar/forum.anna.partners/calder/32/318_2.png) [@Calder](https://forum.anna.partners/u/Calder)\
**Post date:** [August 21, 2026, 2:57am UTC](https://forum.anna.partners/t/json-schema-sampling-call-fails-with-empty-success-false-error-on-cloud-agent-despite-onunsupported-json-object-set/250/1 "2026-08-21T02:57:58Z")

</div>

Hi team,

Related to the two threads on structured sampling – I’m hitting a third, more opaque failure mode for json\_schema-constrained sampling specifically on Cloud Agents, writing it up in case it’s connected.

executa\_id: 1091

tool\_id: tool-calderbuild-wefinance-investment-recommendations-r2q5jdey

ExecutaVersion: 378 (v0.1.5)

Symptom: every invoke of this tool’s generate\_recommendations method fails with:

{“success”: false, “error”: “”, “command\_id”: “”}

No jsonrpc/id fields, no error text – doesn’t match our own tool’s JSON-RPC response shape, so it looks like it comes from a layer above our code.

What I’ve ruled out:

1. Cloud Agent binary caching – reproduced on a brand-new Cloud Agent’s first-ever invocation of this tool.
2. 
  1. A broken/corrupted binary – extracted our shipped darwin-arm64 binary and drove it directly over raw JSON-RPC stdio. It responds correctly to describe/initialize/invoke and emits a well-formed sampling/createMessage request.
  2. 
    1. Sampling broken platform-wide – our sibling tool (Advisor Chat, same llm.sample capability, plain-text response) succeeds immediately on the same Cloud Agent in the same session.
    2. 
      1. Missing permission grant – the Sampling toggle is enabled for this Executa in Installed Apps \> Permissions.
      2. The one real difference between the tool that works and the one that doesn’t: this tool requests a strict json\_schema-constrained completion, and correctly sets the documented onUnsupported: “json\_object” field alongside responseFormat, so the host should downgrade instead of erroring when the model can’t honor strict schema mode. We’re seeing a hard failure instead of a downgrade.

    3. Example failed call:

  3. Request:
  4. {“tool”: “generate\_recommendations”, “arguments”: {“risk\_profile”: “moderate”, “investment\_goal”: “retirement”, “monthly\_income”: 8000, “investment\_horizon”: “10-15 years”, “transactions”: [4 sample transactions]}}

3. Response:
4. {“success”: false, “error”: “”, “command\_id”: “a62c9c02-fe86-4b98-865b-3d1f091b3fec”}

Two more command\_ids from earlier failed attempts, same shape: a6d70289-c2fa-478f-b14c-505ce59ec38a, 5253b1c0-287d-4d87-a2df-5f29d38969eb

Given the “Sampling token missing” thread’s root cause involved a stale platform-side capability/manifest record after certain publish flows, and my own publish history for this executa was slightly unusual (had to manually recreate a missing .anna/executa.json identity cache before republishing), I’m wondering if there’s a similar stale-registration angle here specific to json\_schema-mode sampling.

Would appreciate any pointers on where to look next, or confirmation of whether onUnsupported-based downgrade is fully wired up for Cloud Agents today.

Thanks,

Calder

---

<div class="post-metadata">

**Author:** ![Calder](https://yyz1.discourse-cdn.com/flex033/user_avatar/forum.anna.partners/calder/32/318_2.png) [@Calder](https://forum.anna.partners/u/Calder)\
**Post date:** [August 24, 2026, 8:29am UTC](https://forum.anna.partners/t/json-schema-sampling-call-fails-with-empty-success-false-error-on-cloud-agent-despite-onunsupported-json-object-set/250/2 "2026-08-24T08:29:14Z")

</div>

Follow-up: two more hypotheses eliminated, without spending any Energy.

I inspected grants rather than making new calls (`anna-app apps grants wefinance --json`, CLI v0.1.49), so none of this required a live invocation.

**1. It is not a grant difference between the bundled tools.**

All three executas in this app come back identical – sampling\_grant enabled, llm\_grant complete: true, max\_calls\_per\_day 1000, max\_tokens\_per\_call 4096, and no missing scopes on any of them:

```
Bill Scanner (executa_id 1089) sampling enabled, complete
Advisor Chat (executa_id 1090) sampling enabled, complete <- works
Investment Rec (executa_id 1091) sampling enabled, complete <- fails

```

So the failing tool is not under-granted relative to the sibling that works.

**2. It is not the per-call token ceiling.**

The 4096 cap is not being hit. `ask_advisor` requests maxTokens 2000; `generate_recommendations` requests 3000. Both are under the ceiling, and neither call site overrides its default.

**What that leaves**

Same reverse-RPC path, same Cloud Agent, same session, same grants, same token ceiling. The only remaining structural difference between the sibling call that succeeds and the one that fails is the response format block:

```
"responseFormat": {"type": "json_schema", "json_schema": {...strict: true...}},
"onUnsupported": "json_object"

```

`ask_advisor` sends no responseFormat at all and succeeds (duration\_ms 18682). `generate_recommendations` sends the above and comes back as `{"success": false, "error": "", "command_id": "<uuid>"}` with no jsonrpc/id fields.

I also verified independently that the model layer itself is not the problem: a plain OpenAI-compatible /chat/completions call to my own provider with `response_format: {"type": "json_schema", strict: true}` returns valid schema-conforming JSON. So model capability is ruled out too – which is why I think this sits in the sampling layer’s handling of responseFormat rather than downstream of it.

Happy to run any instrumented build or specific payload you want tested. My account is currently at 1,000/1,000 Energy so I am paused on live runs, but I will re-test the moment that clears and post the result here either way.

---

<div class="post-metadata">

**Author:** ![Calder](https://yyz1.discourse-cdn.com/flex033/user_avatar/forum.anna.partners/calder/32/318_2.png) [@Calder](https://forum.anna.partners/u/Calder)\
**Post date:** [August 24, 2026, 12:22pm UTC](https://forum.anna.partners/t/json-schema-sampling-call-fails-with-empty-success-false-error-on-cloud-agent-despite-onunsupported-json-object-set/250/3 "2026-08-24T12:22:34Z")

</div>

Follow-up: quota top-up landed, and I re-ran the live comparison with fresh Energy.

Same test payload as before, no BYOK involved, both calls made back-to-back in the same Cloud Agent session:

```auto
generate_recommendations -> {"success": false, "error": "", "command_id": "471b68d6-b308-4ccb-8e2b-90af5b5f3815"}

ask_advisor (sibling tool, run immediately after) -> {"success": true, "data": {"success": true, "data": {"advice": "..."}, "duration_ms": 12852}, "command_id": "a346c7aa-b708-4c18-9023-2230ffabf594"}

```

Identical failure signature to before the top-up: empty error string, no jsonrpc/id fields. This rules out account-level Energy exhaustion as a factor — both calls ran under the exact same live conditions (same session, same Cloud Agent, same grants), and only the one sending `responseFormat: {"type": "json_schema", ...}` fails. Still points at the sampling layer’s handling of that field rather than anything account- or quota-related.

Happy to test any specific payload or instrumented build if that’s useful for narrowing it down further.

---

<div class="post-metadata">

**Author:** ![hunter](https://yyz1.discourse-cdn.com/flex033/user_avatar/forum.anna.partners/hunter/32/8_2.png) [@hunter](https://forum.anna.partners/u/hunter)\
**Post date:** [August 27, 2026, 10:16am UTC](https://forum.anna.partners/t/json-schema-sampling-call-fails-with-empty-success-false-error-on-cloud-agent-despite-onunsupported-json-object-set/250/4 "2026-08-27T10:16:13Z")

</div>

Hi @Calder 👋

First off — thank you for an absolutely stellar bug report. The systematic  
elimination across grants, quotas, siblings and payloads saved us a lot of  
time and pointed us straight at the right layer. 🙏

## TL;DR

You found a real platform bug. It’s fixed in **v1.1.0-beta.141** 🎉  
No changes needed on your side — your `responseFormat` +  
`onUnsupported: "json_object"` request was correct all along.

## What was happening 🔍

Two things compounded, both on our side of the fence:

1. **A capability flag was wrong.** One of the models in our sampling  
routing pool was marked as supporting strict `json_schema`, but the  
upstream provider actually coerces it to plain JSON mode internally.  
Because the flag said “supported”, the host **skipped the  
 `onUnsupported` downgrade you asked for** and forwarded the request  
as-is.
2. **A provider quirk.** That provider hard-requires the literal word  
“json” to appear somewhere in the messages when JSON mode is active —  
otherwise it rejects the call instantly. Your prompt (reasonably!)  
relied on `responseFormat` instead of prompt wording, so every call  
failed upstream before generation even started.

So: `ask_advisor` (no `responseFormat`) sailed through, while  
`generate_recommendations` hit the exact intersection of both issues.  
Your instinct that this sat “in the sampling layer’s handling of  
responseFormat rather than downstream of it” was spot on. 🎯

## What we fixed in v1.1.0-beta.141 🛠

- ✅ Corrected the model capability flag — `onUnsupported`-based  
downgrade now kicks in exactly as documented for that model.
- ✅ The host now automatically satisfies the provider’s “json must be  
mentioned” requirement when a `responseFormat` is present, so you  
never need to word your prompts around it.
- ✅ Better errors: sampling provider failures now include the selected  
model and the applied response format in the error message.

After the fix, your exact scenario returns a valid JSON completion, and  
when a downgrade happens you’ll see it reflected in  
`_meta.responseFormat` (`applied`, `downgraded`, `structuredValid`) so  
your tool can decide whether to re-validate against your schema. 📦

## One small thing on your side 💡

The `error: ""` you observed was the platform’s structured error  
(code `-32003`, with a full human-readable message) getting swallowed  
somewhere in your tool’s sampling error handling before it reached the  
invoke result. Worth a quick look — surfacing `err.message` there will  
make any future hiccup much easier to debug. (We’ve also added a  
fallback hint on our side so an empty failure shell can’t happen  
silently again.)

Thanks again for the top-tier report — please give it another run once  
beta.141 is live and let us know how it goes! 🚀

---

<div class="post-metadata">

**Author:** ![Calder](https://yyz1.discourse-cdn.com/flex033/user_avatar/forum.anna.partners/calder/32/318_2.png) [@Calder](https://forum.anna.partners/u/Calder)\
**Post date:** [August 29, 2026, 10:46am UTC](https://forum.anna.partners/t/json-schema-sampling-call-fails-with-empty-success-false-error-on-cloud-agent-despite-onunsupported-json-object-set/250/5 "2026-08-29T10:46:13Z")

</div>

Follow-up: the v1.1.0-beta.141 fix confirmed (thank you!), but live retesting surfaced a second, separate issue on our own side of the fence.

**The good news first** : I re-ran the exact `generate_recommendations` payload from before with fresh Energy, on three different Cloud Agents (destroyed + recreated twice to rule out binary caching). While the failure signature stayed identical, my investigation found a real bug in our own executa: `_request_structured_completion`’s `q.get(timeout=50)` could raise a bare `queue.Empty` on a sampling timeout, and `str(queue.Empty())` is `""` – so a genuine timeout was rendering as the exact same silent empty-error shell as the original bug, just from an unrelated cause. Fixed and published as wefinance-recommend v0.1.6 and v0.1.7 (surfaces both a real JSON-RPC error’s `message` and a diagnosable timeout message now). Verified correct in isolation against the actual shipped binary via the real wire protocol, both with a non-responding fake host (produces the new diagnosable timeout message, not an empty one) and with the exact live payload against a properly-responding fake host (succeeds end-to-end).

**The new finding** : live dashboard tests against app 172 still return the _original_ empty-shell failure unchanged, even after both fixes were published as the “latest” ExecutaVersion for wefinance-recommend. `anna-app apps versions wefinance` shows why:

```auto
in review : v0.2.0 (pinned at submit-review)

```

App 172’s in-review version 0.2.0 appears to have pinned wefinance-recommend at whatever ExecutaVersion existed when I ran `submit-review` on 2026-08-20 (v0.1.5) – publishing v0.1.6/v0.1.7 as standalone ExecutaVersions afterward doesn’t seem to retroactively update that pin, so the Cloud Agent is still running the old, unfixed code regardless of which version is “latest.”

**Question** : is there a way to refresh an in-review App’s pinned tool versions without a full resubmission (which I’d want to avoid mid-review if possible), or does updating a bundled Executa always require cutting and submitting a new App version to actually take effect? Trying to figure out the right way to get the fix in front of your reviewers without disrupting where app 172 already sits in the queue.