jackwener/OpenCLI · error · CommandExecutionError

Jike notifications pagination returned a repeated cursor

Error message

Jike notifications pagination returned a repeated cursor

What it means

To prevent infinite loops, listNotifications tracks a set of JSON-serialized cursors and throws CommandExecutionError if the API hands back the same loadMoreKey again, since the feed would repeat forever without new data.

Source

Thrown at clis/jike/notifications.js:118

        const body = await fetchNotificationsPage(page, loadMoreKey);
        for (const notification of body.data) {
            const row = mapNotification(notification);
            if (seenIds.has(notification.id)) continue;
            seenIds.add(notification.id);
            rows.push(row);
            if (rows.length >= limit) return rows;
        }
        const next = body.loadMoreKey;
        if (next == null) {
            if (rows.length === 0) throw new EmptyResultError('jike notifications', 'No notifications found');
            return rows;
        }
        if (typeof next !== 'object' || Array.isArray(next)) {
            throw new CommandExecutionError('Jike notifications API returned a malformed pagination cursor');
        }
        const cursorKey = JSON.stringify(next);
        if (seenCursors.has(cursorKey)) {
            throw new CommandExecutionError('Jike notifications pagination returned a repeated cursor');
        }
        seenCursors.add(cursorKey);
        loadMoreKey = next;
    }
    throw new CommandExecutionError(`Jike notifications pagination exceeded ${MAX_PAGES} pages before satisfying --limit`);
}

cli({
    site: 'jike',
    name: 'notifications',
    access: 'read',
    description: '即刻通知',
    domain: 'web.okjike.com',
    strategy: Strategy.COOKIE,
    browser: true,
    args: [
        { name: 'limit', type: 'int', default: DEFAULT_LIMIT },
    ],

View on GitHub (pinned to 49907e53dc)

Solutions

Re-run later — often a transient server-side pagination hiccup
Use a smaller --limit so fewer pages are needed
Clear any proxy/cache that could replay the same response
Report to Jike if the same cursor is always returned; update the library if a workaround (e.g. cursor mutation) was shipped

Defensive patterns

Strategy: retry

Try / catch

try {
  await cli('jike', 'notifications').run();
} catch (e) {
  if (String(e.message).includes('repeated cursor')) {
    await sleep(5000); // transient server pagination bug often clears
    // retry once, else surface to user
  } else throw e;
}

Prevention

Retry once with a delay before failing hard
Disable caches/proxies that could replay identical responses
Use smaller --limit to reduce pages required

When it happens

Trigger: The Jike notifications API repeatedly returns the identical loadMoreKey object across consecutive pages, so requesting the next page never advances.

Common situations: Server-side pagination bugs at Jike; accounts with huge notification counts where the backend can't advance; stale cached responses from a proxy; clock/deleted-item quirks causing the cursor to not change.

Related errors

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