Droid BYOK Responses finalizer crashes on sparse or invalid content blocks

[SantaDiegoKairos]

Summary

Droid can crash while finalizing streamed BYOK OpenAI Responses turns when the response contains invalid or sparse tool/content block state.

Observed error:

TypeError: undefined is not an object (evaluating 'f.type')

The same failure class sometimes appears as E.type.

This correlates with Droid logging filtered invalid tool uses immediately before finalization:

[LLM] Filtered out invalid tool uses ... invalidTools=[{}, ...]

Environment

• OS: Windows win32 10.0.26200
• Droid version in logs: 0.121.0
• BYOK: true
• Endpoint shape: OpenAI-compatible /v1/responses
• Affected surfaces observed locally:
  • Factory Desktop / daemon session
  • Droid CLI sessions
  • Zed Droid / ACP wrapper

Reproduction pattern

1. Configure Droid with a BYOK OpenAI-compatible /v1/responses model.
2. Run a tool-heavy agent task where the assistant may emit tool calls.
3. The stream completes far enough for Droid to process tool-use state.
4. Logs show invalid tool uses being filtered, often serialized as empty objects.
5. Droid crashes in/around final content-block finalization with f.type / E.type instead of surfacing a typed assistant message or a recoverable model/tool error.

Structural evidence

Representative sanitized metadata from local logs:

errorMessage: undefined is not an object (evaluating 'f.type')
version: 0.121.0
platform: win32
isByok: true
outputFormat: stream-jsonrpc
preceding invalid tools: totalTools=4 validTools=1 invalidTools=[{},{},{}]

Other occurrences had larger invalid-tool counts such as totalTools=12 validTools=5 invalidTools=[{} x7] and totalTools=30 validTools=3 invalidTools=[{} x27].

No prompts, API keys, OAuth credentials, account identifiers, tool inputs, or full session JSONL payloads are included here.

Expected behavior

• Droid should not crash with a raw .type TypeError when it sees invalid or sparse BYOK stream state.
• Invalid model/tool/content blocks should be discarded, compacted, or converted into a typed recoverable error.
• If the BYOK stream is rejected, the user should see a clear recoverable stream-shape error.
• Logs should report the offending structural path without exposing prompt/tool content.

Server-side mitigations tried

On the BYOK gateway side, I tested/added mitigations for known stream-shape problems:

• JSON-mode guard for default web_search;
• Responses tool_choice compatibility;
• top-level stream error envelopes;
• malformed output-item guards;
• function_call.call_id normalization;
• canonical Responses stream mode with dense local output_index values.

Dense canonical indexes reduced/avoided one observed sparse-index crash path in fresh smoke testing, but Droid should still handle invalid BYOK stream shapes gracefully instead of throwing f.type / E.type.

Separate related symptom

A later image-generation attempt spun in a no-visible-output loop, but current evidence did not show a real image_generation_call invocation. I am treating that as a separate session-runner/no-visible-output issue unless it reproduces with a clear image-generation stream event.

[SantaDiegoKairos]

Update from a fresh 2026-05-13 pass, sanitized/no private logs or credentials included:

• I re-checked the failing path against local Factory/Droid artifacts available on my machine. The locally readable Desktop-side sources do not appear to include the daemon/LLM stream finalizer, so I still cannot send a Droid PR; this remains a Droid-side issue report rather than a patch.
• The strongest client-side hypothesis is unchanged: the BYOK OpenAI Responses stream parser can leave sparse/placeholder content/tool state after filtering invalid tool uses, then ConversationStateManager.finalizeContentBlocks (or equivalent minified path) dereferences .type on an undefined/non-typed block.
• I also re-read Factory BYOK docs: provider: "openai" is documented as the OpenAI Responses API path for OpenAI-compatible custom models. So strict Responses stream handling on this path is expected, but Droid should still treat unknown/invalid/sparse stream blocks as recoverable stream-shape errors, not crash with f.type / E.type.
• Gateway-side mitigations are still useful but not a complete Droid fix. In the AIClient2API fork/PR path I added/updated mitigations around canonical Responses stream defaulting, direct Responses tool_choice.name handling, and a separate Responses system-prompt bug. That can reduce malformed/sparse stream exposure, but it does not remove the need for Droid to compact/filter contentBlocks before finalization.

Suggested Droid-side hardening remains:

function isTypedContentBlock(block: unknown): block is { type: string } {
  return !!block && typeof block === "object" && typeof (block as any).type === "string";
}

const safeContentBlocks = Array.isArray(contentBlocks)
  ? contentBlocks.filter(isTypedContentBlock)
  : [];

Please also avoid using raw Responses output_index as a dense local array index without a local index map, or compact the array before passing it to finalization callbacks.

No prompts, tool payloads, API keys, OAuth credentials, endpoint credentials, or full session logs are included in this update.