jackwener/OpenCLI · error · CommandExecutionError
Section creation did not return a section id
Error message
Section creation did not return a section id
What it means
This CommandExecutionError is thrown when Pinterest's section-create resource call (`pinterestResourceCreate` on 'BoardSectionResource') completes without throwing but the response lacks an `id`. The library treats a section response without `id` as a failed/unusable creation and aborts so callers never receive a row with a bogus or missing sectionId. It usually indicates an unexpected API response shape — a degenerate error body, a wrapped payload, or a Pinterest API schema change.
Source
Thrown at clis/pinterest/board-section-create.js:35
columns: ['sectionId', 'title', 'slug', 'board', 'url'],
func: async (page, kwargs) => {
const { username, slug, path, board: preloadedBoard } = await resolveBoardTarget(page, kwargs.board);
const title = String(kwargs.title ?? '').trim();
if (!title) throw new ArgumentError('section title is required');
await page.goto(`${PINTEREST_BASE}${path}`);
const { boardId } = await resolveBoardId(page, username, slug, path, preloadedBoard);
// The section title goes in `name` here (a `title` key is rejected as a missing parameter).
const created = await pinterestResourceCreate(
page,
'BoardSectionResource',
{ board_id: boardId, name: title },
path,
);
const sectionId = created && created.id;
if (!sectionId) {
throw new CommandExecutionError('Section creation did not return a section id');
}
return [{
sectionId: String(sectionId),
title: created.title || created.name || title,
slug: created.slug || '',
board: `${username}/${slug}`,
url: created.slug ? `${PINTEREST_BASE}${path}${created.slug}/` : '',
}];
},
});
View on GitHub (pinned to 49907e53dc)
Solutions
- Log the raw `created` payload (debug print before the check) to see what the API actually returned
- Re-authenticate / refresh the page session — an expired session often yields degenerate payloads
- Check for a Pinterest API/DOM schema change and update resource parsing to the new id field location
- Retry once; if it reproduces, catch CommandExecutionError and re-list sections to verify whether the section was actually created
Example fix
// before
const created = await pinterestResourceCreate(page, 'BoardSectionResource', { board_id: boardId, name: title }, path);
// after
const created = await pinterestResourceCreate(page, 'BoardSectionResource', { board_id: boardId, name: title }, path);
console.error('create response:', JSON.stringify(created)); // debug payload shape
if (!created?.id) throw new CommandExecutionError('Section creation did not return a section id'); Defensive patterns
Strategy: type-guard
Validate before calling
// after the create call, before using the result:
const sectionId = created && created.id;
if (!sectionId) {
console.error('unexpected create payload:', JSON.stringify(created));
} Type guard
function hasSectionId(created) {
return created != null &&
typeof created === 'object' &&
(typeof created.id === 'string' || typeof created.id === 'number') &&
String(created.id).length > 0;
} Try / catch
try {
const row = await boardSectionCreate({ board, title });
} catch (err) {
if (err instanceof CommandExecutionError && /did not return a section id/.test(err.message)) {
const sections = await boardSections(board); // verify whether it was actually created
const match = sections.find(s => s.title === title);
if (!match) throw err;
return match;
}
throw err;
} Prevention
- Log raw API payloads in dev to detect schema changes early
- Re-authenticate sessions before long-running automation
- Wrap create-then-verify: after create, list sections and confirm presence
- Watch for Pinterest API/DOM changes if you rely on v3 resource endpoints
When it happens
Trigger: The v3 `BoardSectionResource` create returns an object without `id` (e.g. `{ ok: false }` or a wrapped `{ data: {...} }` payload after an API change); the page session is logged-out or rate-limited so the mutation no-ops with an HTTP-200 error body; the board is deleted concurrently mid-call.
Common situations: Pinterest shipping an API/DOM change that renames or nests the id field; expired sessions in long-running automation; transient Pinterest-side failures returning error bodies with status 200.
Related errors
- Pin creation did not return a pin id
- Could not resolve pin "${id}" (does it exist and do you own
- Pin update did not return the updated pin
- Repin did not return a pin id
- Bilibili ${label} API returned a malformed payload
AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29).
Data as JSON: /api/errors/bfe3ec833c3936a9.
Report an issue: GitHub.