jackwener/OpenCLI · error · CommandExecutionError

Xiaohongshu search filter chip did not become active (${deta

Error message

Xiaohongshu search filter chip did not become active (${detail}).

What it means

This CommandExecutionError is thrown by requireFilterApplication when the in-page filter script reports status 'inactive': a requested Xiaohongshu search filter chip (a non-location, non-account option) was clicked but never became active within the 2.5s poll window, or the final settle check found it no longer active. The library throws it because a filter silently not applying would yield results that do not match the requested search scope. The detail field carries the group/option path (e.g. 'sort/popularity') that failed.

Source

Thrown at clis/xiaohongshu/search.js:519

    }
    if (result.status === 'ok') {
        return;
    }
    const detail = typeof result.detail === 'string' ? result.detail : 'unknown';
    if (result.status === 'auth') {
        throw new AuthRequiredError('www.xiaohongshu.com', 'Xiaohongshu search filters require a logged-in browser session');
    }
    if (result.status === 'timeout') {
        throw new TimeoutError(`xiaohongshu search filter ${detail}`, FILTER_SETTLE_SECONDS);
    }
    if (result.status === 'location') {
        throw new CommandExecutionError(`Xiaohongshu location filter was not applied (${detail}); enable browser geolocation permission.`);
    }
    if (result.status === 'capability') {
        throw new CommandExecutionError(`Xiaohongshu account-scoped filter was unavailable (${detail}); verify login and account access.`);
    }
    if (result.status === 'inactive') {
        throw new CommandExecutionError(`Xiaohongshu search filter chip did not become active (${detail}).`);
    }
    throw new CommandExecutionError(`Xiaohongshu search filter layout did not match the expected visible panel (${detail}).`);
}
/**
 * Build a "scroll until enough or plateaued" IIFE used in place of a fixed
 * `autoScroll({ times: N })`. Xiaohongshu's search results page lazy-loads
 * ~5-7 notes per scroll, so the previous `times: 2` capped extraction at
 * ~13 items regardless of `--limit` (see #1471). This helper drives scrolls
 * dynamically:
 *
 *   - count visible `section.note-item` rows (excluding related-search
 *     `.query-note-item` rows)
 *   - if count >= targetCount → break (got enough)
 *   - if two consecutive scrolls add no new rows → break (DOM plateaued,
 *     no more lazy-load available)
 *   - hard cap at `maxScrolls` iterations (default 15) to bound runtime
 *
 * Exported so the rednote adapter (same DOM shape) can reuse it.

View on GitHub (pinned to 49907e53dc)

Solutions

Retry the search once — transient re-renders can delay the chip activation beyond the 2.5s window.
Log the detail field to identify which group/option failed, then drop or replace that filter in your request.
Update the CLI to the latest version, since DOM-shape changes on xiaohongshu.com are the most common root cause.
Run with a logged-in session; some filter options require authentication to activate.
Inspect the page manually in the automation browser to confirm the chip exists and is clickable.

Example fix

// before
await cli.search({ query: 'coffee', filters: [{ group: 'sort', option: 'popular' }] });
// after
try {
  await cli.search({ query: 'coffee', filters: [{ group: 'sort', option: 'popular' }] });
} catch (e) {
  if (/filter chip did not become active/.test(e.message)) {
    await cli.search({ query: 'coffee' }); // retry without the flaky filter
  } else throw e;
}

Defensive patterns

Strategy: try-catch

Validate before calling

const filters = [{ group: 'sort', option: 'time' }];
const supportedGroups = ['sort', 'note_type', 'range'];
if (filters.some(f => !supportedGroups.includes(f.group) || typeof f.option !== 'string')) {
  throw new Error('unsupported xiaohongshu search filter');
}

Type guard

function isFilterRequest(f) {
  return typeof f === 'object' && f !== null
    && typeof f.group === 'string' && typeof f.option === 'string';
}

Try / catch

try {
  await xhs.search({ query, filters });
} catch (e) {
  if (e instanceof CommandExecutionError && /chip did not become active/.test(e.message)) {
    // retry once, then degrade to unfiltered search
    try { await xhs.search({ query, filters }); }
    catch { await xhs.search({ query }); }
  } else throw e;
}

Prevention

Keep the CLI updated since chip selectors depend on the live xiaohongshu.com DOM.
Log the detail field (group/option) to identify flaky filters quickly.
Run logged-in sessions — more filter options activate reliably.
Retry failed filter applications once before degrading to unfiltered search.
Avoid stacking many filters in one request; failures compound.

When it happens

Trigger: Calling the xiaohongshu search command with filter requests (e.g. --filter sort/time) where clicking the chip in the filter panel does not toggle its active class within 2500ms, or the chip loses active state during the FILTER_SETTLE_SECONDS settle check after results reload.

Common situations: Xiaohongshu front-end DOM changes rename or restructure chip elements; a page re-render replaces the chip node mid-click; slow page/network makes the chip activate after the 2.5s poll expires; the requested option is disabled for that query (e.g. filters not offered for this keyword).

Related errors

AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29). Data as JSON: /api/errors/8793b381bdbc23ba. Report an issue: GitHub.