fix: handle type-discriminator format in contentBlockFromData

[kai-agent-free]

Problem

Fixes #533

When content blocks are stored in a database (e.g., for session persistence) and then loaded back, the data may have a flat shape with a type discriminator:

{"type": "toolUseBlock", "name": "greet", "toolUseId": "tu_123", "input": {}}

instead of the nested wrapper format that contentBlockFromData expects:

{"toolUse": {"name": "greet", "toolUseId": "tu_123", "input": {}}}

This happens when blocks are spread ({...block}) or when ORMs/storage layers flatten the nested structure.

Solution

Added fallback handling in contentBlockFromData that checks for the type discriminator when the nested wrapper keys aren't found. Supports toolUseBlock, textBlock, and toolResultBlock — the most common block types encountered in session storage.

Tests

Added 3 tests verifying round-trip deserialization from type-discriminator format:

• ToolUseBlock with type discriminator
• TextBlock with type discriminator
• ToolResultBlock with type discriminator

All 66 tests pass.

[strands-agent]

This repository has been merged into the strands-agents/harness-sdk monorepo and will be archived shortly. All new development happens there.

If this PR is still relevant, please recreate it against the monorepo. The code now lives under strands-ts/. Full commit history was preserved, so your base should be findable.

Apologies for the disruption, and thank you for contributing!