What causes "回复未确认成功：发送后输入框仍未收起（可能被限制或发送失败）" in xpzouying/xiaohongshu-mcp?

Slow down: add longer humanize delays / spacing between replies and reduce daily reply volume

回复未确认成功：发送后输入框仍未收起（可能被限制或发送失败）

Error message

回复未确认成功：发送后输入框仍未收起（可能被限制或发送失败）

What it means

After clicking the submit button, waitReplyAccepted() polls for up to 8s for the textarea.comment-input to disappear from the item, which is how XHS signals a successful reply. If the input is still present after the timeout, the reply was not accepted — possibly rate-limited, content rejected, or a silent send failure.

Source

Thrown at xiaohongshu/notification_reply.go:160

		return fmt.Errorf("读不到回复框提示文字，无法确认回复对象，已中止")
	}
	if nickname != "" && !strings.Contains(*placeholder, nickname) {
		return fmt.Errorf("回复对象不符：期望 %q，实际提示为 %q，已中止", nickname, *placeholder)
	}
	return nil
}

// waitReplyAccepted 等待回复提交完成。
func waitReplyAccepted(item *rod.Element, timeout time.Duration) error {
	deadline := time.Now().Add(timeout)
	for time.Now().Before(deadline) {
		has, _, err := item.Has(`textarea.comment-input`)
		if err == nil && !has {
			return nil
		}
		time.Sleep(300 * time.Millisecond)
	}
	return fmt.Errorf("回复未确认成功：发送后输入框仍未收起（可能被限制或发送失败）")
}

View on GitHub (pinned to 332d196854)

Solutions

Slow down: add longer humanize delays / spacing between replies and reduce daily reply volume
Manually test one reply in the browser to see if XHS shows an error toast or rate-limit message
Check whether the UI changed (input no longer closes on success) and update the success detection (e.g. watch for a new reply node in DOM instead of input closing)
If rate-limited, wait (hours/day) before retrying; retrying immediately worsens restrictions

Example fix

// before
has, _, err := item.Has(`textarea.comment-input`)
if err == nil && !has { return nil }
// after
// success = input closed OR a new reply node appeared under the item
if has, _, _ := item.Has(`textarea.comment-input`); !has { return nil }
if ok, _, _ := item.Has(`div.comment-item .reply-list`); ok { return nil }

Defensive patterns

Strategy: try-catch

Validate before calling

// pace replies beforehand to avoid rate limits
if time.Since(lastReplyAt) < 30*time.Second { return fmt.Errorf("throttle: wait before next reply") }

Try / catch

_, err := action.Reply(ctx, commentID, content)
if err != nil && strings.Contains(err.Error(), "回复未确认成功") {
    // do NOT immediately retry — likely rate-limit or content rejection
    log.Printf("reply %s unconfirmed; backing off", commentID)
    backoffTimer.Reset(10 * time.Minute)
    return err
}

Prevention

Throttle reply volume (e.g. ≥30s gap, daily caps)
Avoid links/sensitive words in reply content
Manually verify in a real browser what the post-submit UI looks like after XHS updates
Treat unconfirmed ≠ failed: the reply may have gone through; check via a fresh fetch before re-sending to avoid duplicates

When it happens

Trigger: Reply() submit click succeeded but: XHS rate-limited the account (frequent replies), the content triggered sensitive-word filtering, the click landed but the form failed client-side validation, or the reply succeeded but the input stays open due to a UI change.

Common situations: Burst-replying to many comments in a short window; replying with links or banned words; account in a restricted state (shadow-ban on comments); recent XHS UI update that keeps the input open after success.

Related errors

AI-assisted analysis of xpzouying/xiaohongshu-mcp@332d196854 (2026-09-05). Data as JSON: /api/errors/e925ebe384b8c5b1. Report an issue: GitHub.