[subidhkhanal]

Fixes #600

Problem. The single-prompt decision loop retries an empty model reply, then makes one final "rescue" call at a higher output ceiling (RECOVERY_MAX_OUTPUT_TOKENS). It only ever recognised an empty reply as the legacy AttributeError("No text content…"). Under the unified execution layer, every adapter now rejects an empty reply before that error can be raised, as LLMExecutionError(RESPONSE_INVALID) (execution/service.py:671). Nothing on this path caught that, so the retries and the rescue call never ran — one empty reply ended the run. Two DeepSeek V4 Pro runs via CommonStack died this way in prod on 2026-10-01 (DJIA 30, 60m): both failed on the first call, after 26s and 31s respectively, with returncode=1 and no agent_runs row written.

pipeline_runner.py:880-890 and :910-919 already handle this correctly. This path, which the leaderboard's llm_agent also uses, never got the same handling.

Fix, in domain/backtesting/portfolio_manager.py:

• The main retry loop now also catches LLMExecutionError with category RESPONSE_INVALID and treats it exactly like the legacy empty-reply case: retry at the configured ceiling, then the rescue call. Every other category (billing, credentials, quota) is re-raised immediately and still ends the run.
• The post-parse truncation retry has the same catch: if its retry comes back RESPONSE_INVALID, the first reply is kept instead of crashing, matching pipeline_runner's equivalent branch.
• The retry count is unchanged — governed by the existing LLM_ESCALATE_CEILING_ON_RETRY setting, same as before this fix.

Tests, in test_escalate_ceiling.py: the existing fake request can now raise LLMExecutionError(RESPONSE_INVALID) (what the real adapters produce) alongside the legacy AttributeError. New cases:

• one empty reply is retried, the next reply is used;
• repeated empty replies reach the rescue call, with the escalate-on-retry flag both off and on;
• a non-RESPONSE_INVALID error (e.g. BILLING_FAILED) is not retried and still ends the run;
• an empty reply during the truncation retry keeps the first reply;
• an end-to-end case through the real AnthropicCompatibleExecutionClient and LLMExecutionService with a scripted adapter returning empty text, run in strict/fail_closed mode as prod runs it — confirming the fix at the actual boundary, not just against a stand-in.

I verified the new tests catch the bug: against unmodified main, 5 of the 6 new tests fail (the request loop stops after one empty reply instead of retrying). With the fix, all 27 tests in the file pass.

Verification run locally:

pytest dashboard/backend/tests/domain/backtesting/ dashboard/backend/tests/backtesting/ dashboard/backend/tests/llm/ dashboard/backend/tests/infrastructure/llm/ -q

1091 passed, 2 skipped, 0 failures.

Known trade-off, stated per the issue's own fix sketch (reuse the same retry/rescue budget): with the default (non-escalating) setting, an empty reply can now cost up to 5 provider calls for that bar instead of ending the run after 1 — this restores the retry behaviour the code was written for rather than introducing new policy. LLM_ESCALATE_CEILING_ON_RETRY=1 cuts this to 2 calls. Note that #556 (an empty reply is released at zero even though the provider billed it) means these retried calls are not yet reflected in a run's recorded spend — a separate, already-filed issue.

Scope note, from a self-review after this diff: a few related things are left out on purpose to keep this PR narrow —

• RESPONSE_INVALID also covers non-empty-reply failures (a malformed request, a bad adapter response), so the new retry treats those the same way the issue's sketch asks for the empty-reply case to be treated. Giving "empty reply" its own error category, so request/response bugs aren't silently retried under the same label, would be a cleaner design but touches the execution layer and pipeline_runner too — worth its own issue;
• rejected attempts aren't counted in the run's llm_calls/token totals, which is exactly fix(llm): an empty reply is released at zero though the provider billed it #556's scope, not reintroduced here.

---

Review follow-up (maintainer commit on this branch). This replaces the "retry count is unchanged", "Known trade-off" and "Scope note" paragraphs above.

• An empty reply now carries its own marker, LLMExecutionError.for_empty_reply(). The category is still RESPONSE_INVALID. The three adapters raise it, because that is where prod's empty replies are actually rejected (not service.py), and the service raises it as a backstop. Retries are keyed on is_empty_reply(), so a refused request, or a result that fails validation after settlement, is no longer retried or billed again. This applies to both the single-prompt and pipeline paths.
• An execution-layer empty reply goes straight to the rescue call: 2 calls instead of 5, whatever LLM_ESCALATE_CEILING_ON_RETRY says. The legacy client is unchanged.
• Analytics records empty_response instead of internal_error. This touches the allow-list and the SQLite/Postgres CHECKs, and a guard test covers them.
• Unchanged by design: an empty rescue still ends a hosted run, because 3e27402e keeps response errors fatal there.

[vercel]

@subidhkhanal is attempting to deploy a commit to the allan-feng's projects Team on Vercel.

A member of the Team first needs to authorize it.