jackwener/OpenCLI · error · CommandExecutionError

Xianyu publish result was not confirmed before timeout

Error message

Xianyu publish result was not confirmed before timeout

What it means

Publish clicked submit, then polls buildDetectSuccessEvaluate() 10 times (1.5s apart) for status 'published' or 'failed'. If neither appears before the loop ends — and no explicit failure message was captured — the CLI throws this timeout error, advising you to open finalUrl and check manually. The listing may or may not have actually gone through.

Source

Thrown at clis/xianyu/publish.js:470

                itemId = String(result.item_id || '').replace(/\D/g, '');
                return [{
                    status: 'published',
                    item_id: itemId,
                    title: data.title.slice(0, 50),
                    price: `¥${data.price}`,
                    condition: data.condition,
                    url: result.url || finalUrl,
                    message: '发布成功',
                }];
            }

            if (result?.status === 'failed') {
                failReason = result.message || '发布失败';
                break;
            }
        }

        throw new CommandExecutionError(failReason || 'Xianyu publish result was not confirmed before timeout', `Open ${finalUrl} and verify whether the listing was published.`);
    },
});

export const __test__ = {
    CONDITION_CHOICES,
    MAX_IMAGES,
    validateImagePaths,
    normalizePublishArgs,
    buildPublishUrl,
    getCurrentPageUrl,
    buildFillFormEvaluate,
    buildSelectCategoryEvaluate,
    buildFindFileInputSelectorEvaluate,
    buildDetectSuccessEvaluate,
};

View on GitHub (pinned to 49907e53dc)

Solutions

Open the finalUrl from the error hint and check manually whether the item was published; it may have succeeded after the timeout.
Simply retry the publish — check your listings first to avoid duplicates.
If timeouts are routine, increase the poll count/duration in the publish flow around clis/xianyu/publish.js:446-468.
Check for goofish risk-control notices (verification required) on the account.

Example fix

// before: fixed 10 x 1.5s poll
for (let i = 0; i < 10; i++) { await page.wait(1.5); ... }
// after: longer budget for slow publishes
for (let i = 0; i < 30; i++) { await page.wait(1.5); ... }

Defensive patterns

Strategy: fallback

Try / catch

try {
  return await publish(data);
} catch (e) {
  if (String(e.message).includes('not confirmed before timeout')) {
    const url = e.message.match(/Open (\S+) and/)?.[1];
    // check listings manually or via API before re-publishing to avoid duplicates
    const published = await checkListingExists(url);
    if (!published) return publish(data);
  }
  throw e;
}

Prevention

Always open the finalUrl in the error hint to confirm outcome before retrying.
Don't blindly retry — dedupe against existing listings first.
Under persistent timeouts, lengthen the poll loop (clis/xianyu/publish.js:446).
Watch for account risk-control states that delay or hold listings.

When it happens

Trigger: `xianyu publish` where ~15s of polling never yields status 'published' or 'failed': slow server-side processing, the success detector's DOM markers changed, or the page navigated somewhere the detector doesn't understand.

Common situations: Goofish under heavy load delaying listing creation past 15s; risk-control review holding the listing; front-end redesign breaking buildDetectSuccessEvaluate; upload still processing when the poll window expired.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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