Summary
OpenCLI autofix repaired this adapter locally, and the retry passed.
Adapter
- Site:
xiaohongshu
- Command:
search
- OpenCLI version:
1.7.18
Original failure
- Error code:
EMPTY_RESULT (silent — exit 0 with [], no error envelope)
The adapter at clis/xiaohongshu/search.js returns [] for every query, including queries that visibly have results in a logged-in Chrome tab. opencli xiaohongshu feed (intercept-mode) works fine in the same browser, ruling out auth/session issues.
Root cause
page.evaluate() returns the daemon exec envelope { session, data }, not the raw evaluated value. The adapter compares/iterates it directly:
if (waitResult === 'login_wall') — never true because waitResult is {session, data: 'login_wall'}, so an actual login wall would be silently mis-classified.
Array.isArray(payload) — always false because payload is {session, data: [...items...]}, so the 10+ extracted items fall through to the [] fallback.
Secondary issue: WAIT_FOR_CONTENT_JS resolves on the first section.note-item element, but xiaohongshu's virtual list renders section shells before their inner titles populate, racing autoScroll/extract against lazy fill-in. The trace-time state snapshot looks healthy because it's captured after the extract returned empty.
Local fix summary
- Added an
unwrap(v) helper that returns v.data when v looks like the {session, data} envelope, else v (tolerant of any pre-envelope return shape).
- Applied it to both
page.evaluate(WAIT_FOR_CONTENT_JS) and page.evaluate(buildSearchExtractJs(...)).
- Tightened
WAIT_FOR_CONTENT_JS to require ≥3 section.note-item elements with non-empty title text, with timeout raised 5s → 8s.
Verified locally: opencli xiaohongshu search "龙虾电脑" --limit 10 now returns 10 results.
Issue filed by OpenCLI autofix after a verified local repair.
Summary
OpenCLI autofix repaired this adapter locally, and the retry passed.
Adapter
xiaohongshusearch1.7.18Original failure
EMPTY_RESULT(silent — exit 0 with[], no error envelope)The adapter at
clis/xiaohongshu/search.jsreturns[]for every query, including queries that visibly have results in a logged-in Chrome tab.opencli xiaohongshu feed(intercept-mode) works fine in the same browser, ruling out auth/session issues.Root cause
page.evaluate()returns the daemonexecenvelope{ session, data }, not the raw evaluated value. The adapter compares/iterates it directly:if (waitResult === 'login_wall')— never true becausewaitResultis{session, data: 'login_wall'}, so an actual login wall would be silently mis-classified.Array.isArray(payload)— always false becausepayloadis{session, data: [...items...]}, so the 10+ extracted items fall through to the[]fallback.Secondary issue:
WAIT_FOR_CONTENT_JSresolves on the firstsection.note-itemelement, but xiaohongshu's virtual list renders section shells before their inner titles populate, racingautoScroll/extractagainst lazy fill-in. The trace-time state snapshot looks healthy because it's captured after the extract returned empty.Local fix summary
unwrap(v)helper that returnsv.datawhenvlooks like the{session, data}envelope, elsev(tolerant of any pre-envelope return shape).page.evaluate(WAIT_FOR_CONTENT_JS)andpage.evaluate(buildSearchExtractJs(...)).WAIT_FOR_CONTENT_JSto require ≥3section.note-itemelements with non-empty title text, with timeout raised 5s → 8s.Verified locally:
opencli xiaohongshu search "龙虾电脑" --limit 10now returns 10 results.Issue filed by OpenCLI autofix after a verified local repair.