Failed to set ${fieldName}. Expected "${text}", got "${actua

Error message

Failed to set ${fieldName}. Expected "${text}", got "${actual}". Debug screenshot: /tmp/xhs_publish_${fieldName}_debug.png

What it means

Thrown by fillField during the verify phase: after inserting text, the field's normalized value did not equal the expected text. result.ok was false and result.actual holds whatever the field actually contained. A debug screenshot is saved before throwing.

Source

Thrown at clis/xiaohongshu/publish.js:406

        fireInput(el, expectedText);
        el.dispatchEvent(new Event('change', { bubbles: true }));
        el.blur();
        const actual = normalize(el.innerText || el.textContent || '');
        return { ok: actual === normalize(expectedText), actual };
      })(${JSON.stringify(located.sel)}, ${JSON.stringify(text)})
    `);
        }
        catch {
            result = await applyInPage();
        }
    }
    else {
        result = await applyInPage();
    }
    if (!result?.ok) {
        await page.screenshot({ path: `/tmp/xhs_publish_${fieldName}_debug.png` });
        const actual = typeof result?.actual === 'string' ? result.actual : '';
        throw new Error(`Failed to set ${fieldName}. Expected "${text}", got "${actual}". Debug screenshot: /tmp/xhs_publish_${fieldName}_debug.png`);
    }
}
/**
 * Add topic hashtags by driving the editor's native inline "#" flow.
 *
 * Modern XHS creator-center editors turn a "#keyword" typed into the note body
 * into a linked topic entity only after the author picks an item from the
 * suggestion dropdown that appears while typing. There is no standalone
 * "添加话题" search input anymore, so we type directly into the body editor.
 *
 * For each topic we:
 *   1. focus the body contenteditable and move the caret to the end,
 *   2. type " #<topic>" using native CDP insertion (falls back to execCommand)
 *      so XHS fires its inline suggestion dropdown,
 *   3. wait for the dropdown, then click the suggestion whose text best matches
 *      the topic (falling back to the first suggestion, then to Enter),
 *   4. confirm a topic chip/link was produced before moving on.
 *

View on GitHub (pinned to 49907e53dc)

Solutions

Shorten the text to respect XHS title/body length limits and simplify special characters.
Look at /tmp/xhs_publish_<field>_debug.png to see what the field actually holds.
Retry with a longer wait before/after inserting text.
Update the CLI if XHS changed editor behavior; file an issue with the screenshot.

Example fix

// before
await xhs.publish({ title: 'x'.repeat(100), ... }); // exceeds XHS title limit
// after
const title = 'x'.repeat(100).slice(0, 20); // XHS title cap
await xhs.publish({ title, ... });

Defensive patterns

Strategy: try-catch

Validate before calling

// respect XHS limits before calling
if (opts.title && opts.title.length > 20) throw new Error('XHS title max ~20 chars');
if (opts.content && opts.content.length > 1000) throw new Error('body too long');

Try / catch

try {
  await xhs.publish(opts);
} catch (err) {
  const m = err.message.match(/Failed to set (\w+)\. Expected "([\s\S]*)", got "([\s\S]*)"/);
  if (m) console.error(`Field ${m[1]} mismatch: got "${m[3]}" — check limits/characters`);
  else throw err;
}

Prevention

Keep titles within XHS length limits
Avoid exotic characters/emoji that editors rewrite
Inspect the debug screenshot to see actual field content
Retry with longer waits on slow pages

When it happens

Trigger: XHS editor truncated or reformatted the text (length limits, emoji/mention transformation); insertText went to the wrong element or was swallowed; asynchronous editor state lagged the immediate verification; IME/placeholder interference.

Common situations: Titles over XHS's character limit; content with special characters the editor rewrites; very slow pages where verification ran before the editor updated.

Related errors

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