fix(langchain): coerce non-str nl/sql in format_recall_content

[Bartok9]

Summary

• Coerce non-str nl/sql values in format_recall_content so recall formatting never embeds TypeError risk when memory rows hold non-strings.

Verification

• Direct module load proof: format_recall_content([{"nl": 123, "sql": None}]) → 1. "123" with empty SQL fence.

License

sdk/** Apache-2.0.

Summary by CodeRabbit

• Bug Fixes

  • Improved recall content formatting when recall rows are malformed, such as non-text values and missing SQL.
  • Ensured single-item recall results display with the expected row numbering.

• Tests

  • Added unit coverage for malformed recall inputs to prevent future formatting regressions.

• Documentation

  • Reformatted README code examples for consistent indentation and alignment.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3b4d3bd4-c974-4887-8dba-2a037db4b9ae

📥 Commits

Reviewing files that changed from the base of the PR and between a56f776 and a8c248d.

📒 Files selected for processing (1)

• sdk/wren-langchain/README.md

---

Walkthrough

A unit test was added to verify format_recall_content handles a non-string nl value and None SQL. README API and configuration examples were also reformatted without semantic changes.

Changes

Wren LangChain updates

Layer / File(s)	Summary
Malformed recall formatting test sdk/wren-langchain/tests/unit/test_format_malformed.py	Adds coverage for coercing and quoting a non-string nl value when formatting a single recall row with null SQL.
README example formatting sdk/wren-langchain/README.md	Normalizes whitespace and alignment in Direct Python API and configuration examples without changing their semantics.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Possibly related PRs

• Canner/WrenAI#2521: Adds related coverage for format_recall_content formatting and numbering behavior.
• Canner/WrenAI#2563: Tests malformed recall hit shapes in the same rendering path.

Suggested labels: python

Suggested reviewers: goldmedal

Poem

A bunny found a row askew,
With nl numbered one-two-three too.
Null SQL caused no fright,
The formatter made it right—
“123” now hops into view!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: coercing non-string recall fields in format_recall_content.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@sdk/wren-langchain/tests/unit/test_format_malformed.py`:
- Around line 126-128: Update test_format_recall_coerces_non_str_nl_sql to
assert the complete formatted output, including the SQL section and its empty
code fence when sql is None. Use a non-string SQL input as well if the test is
intended to verify SQL coercion, and replace the partial substring assertion
with an exact expected-output assertion.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9995ca5f-f301-47da-874a-2da53ea146f9

📥 Commits

Reviewing files that changed from the base of the PR and between d472877 and a56f776.

📒 Files selected for processing (1)

• sdk/wren-langchain/tests/unit/test_format_malformed.py

[coderabbitai]

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Assert the SQL output too.

Line [128] verifies only the NL value, so the test would pass if the SQL fence were omitted or rendered incorrectly. Assert the complete output, including the empty SQL fence required for sql=None; use a non-string SQL value too if coercion is part of this test’s contract.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@sdk/wren-langchain/tests/unit/test_format_malformed.py` around lines 126 -
128, Update test_format_recall_coerces_non_str_nl_sql to assert the complete
formatted output, including the SQL section and its empty code fence when sql is
None. Use a non-string SQL input as well if the test is intended to verify SQL
coercion, and replace the partial substring assertion with an exact
expected-output assertion.

[goldmedal]

Closing this one — there's no production change in it.

The diff touches only sdk/wren-langchain/README.md and a test. On main, format_recall_content already reads

nl = row.get("nl_query") or row.get("nl") or ""
sql = row.get("sql_query") or row.get("sql") or ""

so {"nl": 123, "sql": None} already renders 1. "123" today and the new assertion passes without any behavior change. The remaining hunk is unrelated comment-alignment reformatting in the README, which I'd rather not carry as part of a fix(langchain) commit.

If you'd like the malformed-input case covered, a test-only PR adding it to tests/unit/test_format_malformed.py (where the sibling cases live) with no README churn and a test: prefix would be welcome.

[Bartok9]

You're right — main already coerces via the or chain, so there's no production change here. Closing. Thanks for the look!