fix(provider): drop empty content messages after interleaved reasoning filter

[jpvelasco]

Issue for this PR

Fixes #17705

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The interleaved reasoning filter in normalizeMessages() strips reasoning parts from assistant messages and moves them to providerOptions. When an assistant message contains only reasoning parts (no text, no tool-call), this leaves content: [], which Bedrock's ConverseAPI rejects with a validation error. The session is permanently broken after this.

The empty content guard at lines 54-72 cannot catch this because it runs before the interleaved filter.

The fix adds a check after filtering reasoning parts: if filteredContent is empty, the message is dropped. This follows the same pattern used by the existing empty content guard at line 68.

How did you verify your code works?

• 6 new unit tests covering reasoning-only messages (single/multiple parts, bedrock, openai-compatible, mixed content, non-interleaved models)
• 115 existing transform tests pass with 0 regressions
• Typecheck passes (bun turbo typecheck --filter=opencode)
• Live tested on Bedrock with amazon-bedrock/zai.glm-4.7 (the only Bedrock model currently with interleaved: { field: "reasoning_content" }). Before the fix: crashes at step 14 with validation error. After the fix: completed 199 steps with 0 errors.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my searches, I found one potentially related PR:

Related PR:

• fix(provider): handle empty content for bedrock/openai-compatible APIs #17396 - fix(provider): handle empty content for bedrock/openai-compatible APIs
  • fix(provider): handle empty content for bedrock/openai-compatible APIs #17396
  • This appears to address similar issues with empty content handling for Bedrock and OpenAI-compatible APIs, which is closely related to the current PR's focus on dropping empty content messages after the interleaved reasoning filter.

The other PRs found (like #16750 and #14637) deal with related normalizeMessages and interleaved reasoning concerns, but they appear to address different specific issues rather than duplicates.

Note: PR #17712 is the current PR you're checking, so it's not listed as a duplicate of itself.

[robinmordasiewicz]

We independently hit this bug in a fork while using an openai-compatible provider routing to Anthropic models. Reasoning-only assistant messages became content: [] after the interleaved filter stripped them, causing validation errors downstream.

We arrived at the same fix — if (filteredContent.length === 0) return undefined plus a .filter() on the outer .map(). Tested against an openai-compatible provider with interleaved: { field: "reasoning_content" } and confirmed the crash is gone.

Clean, minimal fix. Would be great to see this merged.