Skip to content

fix(xiaohongshu): map OpenCLI 2.0 {ok, data} note rows in read - #861

Open
dbisina wants to merge 1 commit into
Panniantong:mainfrom
dbisina:fix/xiaohongshu-read-opencli-envelope
Open

dbisina wants to merge 1 commit into
Panniantong:mainfrom
dbisina:fix/xiaohongshu-read-opencli-envelope

Conversation

@dbisina

@dbisina dbisina commented Oct 26, 2026

Copy link
Copy Markdown

Fixes #844.

agent-reach xiaohongshu read <note link> returned ok: true with title, author, published_at and text all null, and the note body only inside raw. In _opencli_read the {field, value} rows are flattened into one note only when opencli_call returns a bare list. OpenCLI 2.0 returns {"ok": true, "data": [...]}, so that branch never ran and each row was turned into its own empty item.

The fix unwraps data when it is a list, before the existing check, so both shapes produce the single note item the code was written to produce (title, author, text from content, and url set to the link passed in). This also fixes a second case in the same spot: an envelope with an empty data list is falsy, so opencli_items fell through to building an item from the envelope itself and reported success; it now reports NOT_FOUND. The change is in agent_reach/channels/xiaohongshu.py only (three lines).

New tests/test_xiaohongshu_read.py covers the bare list (it passed before), the envelope from the issue, and the empty envelope. The envelope and empty-envelope cases fail without the change.

Checks, from CONTRIBUTING: pytest (477 passed, 2 skipped), ruff check agent_reach tests and mypy agent_reach all pass, on Windows with Python 3.13.

Not done: the live check. CONTRIBUTING asks for agent-reach check xiaohongshu --text output for a changed channel. I could not run one: I have no Xiaohongshu login and no OpenCLI 2.0 browser session, so this is verified against the exact output shape quoted in the issue, not against a real note. I did not touch the README or the changelog.

xiaohongshu read flattened OpenCLI's {field, value} rows into one note only
when the output was a bare list. OpenCLI 2.0 wraps them as
{"ok": true, "data": [...]}, so read returned ok with every unified
field null and the note body only inside raw. An empty envelope was also
turned into a success item built from the envelope itself.

Unwrap the envelope before flattening, so both shapes give one note item and
an empty result is reported as NOT_FOUND.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(xiaohongshu): read 假成功 —— field/value 展平只认裸 list,漏掉 OpenCLI 2.0 的 {ok, data} envelope

1 participant