jackwener/OpenCLI · error · CommandExecutionError

Sales Navigator messaging threads API reached the ${maxPages

Error message

Sales Navigator messaging threads API reached the ${maxPages}-page safety cap before collecting ${limit} conversations

What it means

fetchInboxRows enforces a --max-pages safety cap (default 30). If it hits that cap while the API still reports more pages (hasMorePages) and fewer than --limit conversations were collected, it throws rather than returning partial or misleading results.

Source

Thrown at clis/linkedin/salesnav-inbox.js:160

    const pageRows = parseSalesnavThreads(json);
    if (pageRows.length === 0) break;
    for (const row of pageRows) {
      if (seen.has(row.thread_id)) continue;
      seen.add(row.thread_id);
      rows.push(row);
      if (rows.length >= limit) break;
    }
    const last = pageRows[pageRows.length - 1];
    const next = last?.next_page_starts_at;
    hasMorePages = Boolean(next);
    if (!next) break;
    if (next === pageStartsAt) {
      throw new CommandExecutionError('Sales Navigator messaging threads API returned the same cursor twice');
    }
    pageStartsAt = next;
  }
  if (rows.length < limit && hasMorePages && pagesFetched >= maxPages) {
    throw new CommandExecutionError(`Sales Navigator messaging threads API reached the ${maxPages}-page safety cap before collecting ${limit} conversations`);
  }
  return rows.slice(0, limit).map((row, index) => ({ ...row, rank: index + 1 }));
}

export { THREAD_DECORATION, THREADS_BASE };

cli({
  site: 'linkedin',
  name: 'salesnav-inbox',
  access: 'read',
  description: 'List LinkedIn Sales Navigator message conversations with API pagination',
  domain: LINKEDIN_DOMAIN,
  strategy: Strategy.UI,
  browser: true,
  args: [
    { name: 'limit', type: 'number', default: DEFAULT_LIMIT, help: 'Maximum conversations to return (1-500)' },
    { name: 'max-pages', type: 'number', default: 30, help: 'Maximum Sales Navigator API pages to fetch' },
    { name: 'unread-only', type: 'bool', default: false, help: 'Return only unread conversations' },

View on GitHub (pinned to 49907e53dc)

Solutions

Increase --max-pages (e.g. --max-pages 100) to allow more cursor hops.
Lower --limit so it fits within the page budget.
Re-run the command; partial API responses (small rows per page) may resolve on retry.
Check the inbox is not flooded with archived threads that inflate page count.

Example fix

// before
linkedin salesnav-inbox --limit 500
// after
linkedin salesnav-inbox --limit 500 --max-pages 100

Defensive patterns

Strategy: validation

Validate before calling

const limit = 500, maxPages = 30;
if (limit > maxPages * 10) console.warn(`limit ${limit} likely exceeds ${maxPages} pages; raise --max-pages`);

Try / catch

try { await fetchInboxRows(page, { limit, maxPages }); } catch (e) { if (/safety cap/.test(e.message)) { return fetchInboxRows(page, { limit, maxPages: maxPages * 2 }); } throw e; }

Prevention

Set --max-pages proportional to --limit (roughly limit / rows-per-page, with headroom).
Lower --limit if you don't need the whole inbox.
Remember the default max-pages is 30.
Watch for small page sizes in big inboxes; they exhaust the cap sooner.

When it happens

Trigger: rows.length < limit, hasMorePages is true, and pagesFetched >= maxPages — the inbox has more conversations than maxPages iterations of ~page-size rows can deliver.

Common situations: Large Sales Navigator inbox with hundreds of threads while default max-pages=30 is too small; user raised --limit (up to 500) without raising --max-pages; slow page sizes shrink rows-per-page so the cap is exhausted early.

Related errors

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