jackwener/OpenCLI · error · CommandExecutionError
Pixiv bookmark archive failed: ${error?.message || error}
Error message
Pixiv bookmark archive failed: ${error?.message || error} What it means
The final catch-all for the bookmark archive run: if any error escapes the download/commit loop that is not already a CommandExecutionError, it is wrapped in this generic 'Pixiv bookmark archive failed' message after rolling back all committed plans (cleanupPlan in reverse order). Typed CommandExecutionErrors (like the ones above) pass through unchanged.
Source
Thrown at clis/pixiv/bookmark-download.js:226
const destination = plan.kind === 'novel'
? commitNovelFile(plan)
: await commitIllustPlan(plan, cookies);
committed.push(plan);
const id = type === 'novel' ? plan.row.novel_id : plan.row.illust_id;
results.push({
rank: plan.row.rank,
type,
id,
title: plan.row.title,
download_status: 'success',
path: destination,
});
}
return results;
} catch (error) {
for (const plan of committed.reverse()) cleanupPlan(plan);
if (error instanceof CommandExecutionError) throw error;
throw new CommandExecutionError(`Pixiv bookmark archive failed: ${error?.message || error}`);
}
},
});
View on GitHub (pinned to 49907e53dc)
Solutions
- Read the inner error.message to find the real root cause (fs vs network vs auth)
- Re-run the archive after fixing the underlying condition; previously committed files are protected by the overwrite guard
- Check disk space and permissions on the output root
- Verify the Pixiv session is still valid if later items fail after the first few succeed
- Wrap known raw error sources in CommandExecutionError for clearer typed failures
Example fix
// before
throw new CommandExecutionError(`Pixiv bookmark archive failed: ${error?.message || error}`);
// after: keep the cause for diagnostics
const wrapped = new CommandExecutionError(`Pixiv bookmark archive failed: ${error?.message || error}`);
wrapped.cause = error;
throw wrapped; Defensive patterns
Strategy: try-catch
Validate before calling
// preflight before the archive loop
if (!fs.existsSync(outputRoot) || fs.statSync(outputRoot).code === undefined) {
fs.mkdirSync(outputRoot, { recursive: true });
}
if (fs.statSync(outputRoot).mode & 0o200 === 0) throw new Error('output root not writable'); Type guard
function isCommandExecutionError(e) {
return e instanceof Error && e.constructor.name === 'CommandExecutionError';
} Try / catch
try {
await pixivBookmarkDownload({ page, type, output });
} catch (err) {
if (err instanceof CommandExecutionError && !/archive failed/.test(err.message)) throw err; // typed, specific
console.error(`Archive aborted: ${err.message}`);
// committed items were rolled back; safe to retry the whole run
} Prevention
- Check disk space and permissions before multi-item archives
- Retry the run after fixing the root cause — the overwrite guard makes it idempotent
- Keep the Pixiv session alive for the whole run
- Surface raw fs/network errors early with typed wrappers
When it happens
Trigger: Any non-CommandExecutionError thrown inside the committed-results try block — e.g. novel file commits failing with raw fs errors, network fetch of bookmarks failing mid-loop, unexpected null dereferences in the results loop, or a download tool throwing a raw Error.
Common situations: Network drop partway through archiving multiple pages; disk filling up mid-archive; a novel download path hitting an unexpected fs error (EACCES/ENOSPC); a library bug throwing a plain Error; process-level interruptions surfacing as generic errors.
Related errors
- Pixiv illustration ${plan.illustId} download failed: ${error
- No Pixiv bookmarks matched the requested page.
- Pixiv bookmark archive contains a duplicate download target:
- Pixiv PHPSESSID cookie missing
- Pixiv PHPSESSID prefix unparseable
AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29).
Data as JSON: /api/errors/635ee9cf8554c71f.
Report an issue: GitHub.