Greptile Summary

This PR fixes a false-positive poll intent rejection on action="send" by replacing the broad hasPollCreationParams check with a new, stricter hasRealPollIntent function that only considers a non-empty pollQuestion or pollOption as real poll intent — metadata-only fields like pollDurationHours, pollMulti, pollAnonymous, and pollPublic no longer cause sends to be incorrectly rejected. The fix is well-scoped, the new hasPollCreationParams function is preserved for actual poll creation paths, and the regression tests cover the key boundary conditions clearly.

Confidence Score: 5/5

Safe to merge — the fix is narrowly scoped, correct, and backed by comprehensive regression tests.

No P0 or P1 findings. The narrowing of the send-side poll intent guard from hasPollCreationParams to hasRealPollIntent is logically sound: readSnakeCaseParamRaw correctly handles both camelCase and snake_case variants, all edge cases (empty arrays, whitespace strings, non-string entries, null/undefined) are handled defensively, and the original broader function is preserved for actual poll creation paths downstream. Test coverage is thorough at both unit and integration levels.

No files require special attention.

_{Reviews (1): Last reviewed commit: "test: align send validation with real po..." | Re-trigger Greptile}

Thanks for the context here. I did a careful shell check against current main, and the useful part of this older PR is already implemented there.

Close: current main now has the same-or-better poll metadata send behavior through a merged replacement PR that preserved source credit, so this conflicting source branch no longer has unique mergeable work.

Root-cause cluster
Relationship: superseded
Canonical: #93441
Summary: This source PR and the merged replacement address the same outbound message.send false positive; the replacement is now the canonical merged implementation.

Members:

• canonical: fix(outbound): ignore schema-padded poll metadata on send #93441 - Merged replacement PR explicitly repairs this source PR, carries source credit, and implements the current-main channel-extra metadata behavior.
• partial_overlap: fix(outbound): stop schema-padded poll modifiers from blocking send #89601 - Merged earlier fix addressed shared poll modifiers but intentionally left channel-extra metadata strict, which this PR and the replacement later covered.
• same_root_cause: message.send schema overexposes poll/components/modal causing GPT auto-population breakages #43015 - The broader issue captured schema-padded poll metadata causing plain send failures and was closed by the merged replacement PR.
• partial_overlap: message tool: Feishu send action polluted by poll schema/guard prevents file send #42820 - The open Feishu report shares the poll-schema send false-positive symptom but may retain broader channel/file-send context beyond this source PR.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

So I’m closing this older PR as already covered on main rather than keeping a mostly-duplicated branch open.

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

AI-generated review comment.
I tested this PR locally on the PR branch and the targeted checks pass:

• Installed dependencies with corepack pnpm install --frozen-lockfile
• Ran targeted Vitest coverage for the touched behavior:
  • src/poll-params.test.ts
  • src/infra/outbound/message-action-runner.send-validation.test.ts
  • src/infra/outbound/message-action-runner.core-send.test.ts
• Ran oxlint on touched files: 0 warnings / 0 errors
• Ran oxfmt --check on touched files: passed

I also ran a focused source-level probe mirroring the failure mode we observed with GPT/default-filled tool params:

• { pollQuestion: "", pollOption: [], pollDurationHours: 1, pollMulti: false }
  • hasPollCreationParams(...) === true
  • hasRealPollIntent(...) === false
• { pollDurationHours: 24, pollMulti: false }
  • hasPollCreationParams(...) === true
  • hasRealPollIntent(...) === false
• { pollQuestion: "Lunch?", pollDurationHours: 1 }
  • hasRealPollIntent(...) === true
• { pollOption: ["Yes", "No"], pollDurationHours: 1 }
  • hasRealPollIntent(...) === true

This matches the intended behavior: metadata/default-only poll fields no longer block action: "send", while real poll content still requires action: "poll".

Verdict: I think this is safe to merge. The change is small, targeted, and directly addresses the false-positive poll guard without changing actual action: "poll" creation/validation behavior.

Non-blocking suggestions:

1. Clean up the PR description. It still contains template text such as “Describe the problem and fix in 2–5 bullets”.
2. Consider adding an explicit regression test for the GPT-5.4/5.5 default-filled params shape, e.g. pollQuestion: "", pollOption: [], pollDurationHours: 1 or 24. The existing tests cover the behavior substantively, but an exact-shape regression would make the original failure mode obvious.
3. The PR intentionally allows action: "send" with poll metadata-only fields, even odd ones like negative durations. That seems like the right tradeoff because metadata-only poll fields should be ignored on the send path, but a short code comment may help future maintainers understand why send does not validate those metadata fields.

Real behavior proof from a Discord production deployment that matches this PR's fix shape.

Environment:

• OpenClaw: 2026.6.1 (2e08f0f)
• @openclaw/discord: 2026.6.1
• Channel: Discord guild channel
• Model/runtime: github-copilot/gpt-5.5 via embedded agent

A normal text reply was generated, but message.send failed before delivery because schema/default poll metadata was interpreted as poll intent:

{
  "action": "send",
  "channel": "discord",
  "target": "channel:<redacted>",
  "message": "<plain text>",
  "pollQuestion": "",
  "pollOption": [],
  "pollDurationHours": 24,
  "pollMulti": false,
  "pollOptionIndex": 1,
  "pollDurationSeconds": 60,
  "pollAnonymous": false,
  "pollPublic": false
}

Observed error:

Poll fields require action "poll"; use action "poll" instead of "send".

I compared this exact payload against the current installed hasPollCreationParams logic. With the already-merged #89601-style behavior, empty pollQuestion/pollOption and shared modifiers (pollDurationHours, pollMulti) no longer trigger the guard. But pollDurationSeconds: 60 is still a channel-extra poll field, so it still returns true and blocks action="send".

This PR's hasRealPollIntent approach should fix the exact failure: the above payload has no non-empty pollQuestion and no non-empty pollOption, so it should not block a plain send; real poll content (pollQuestion: "Lunch?" or pollOption: ["A", "B"]) would still be rejected under action="send" and routed to action="poll" as intended.

Impact: message loss in Discord channel sessions. The user sees the bot react/acknowledge, but no answer is posted.

Clownfish 🐠 reef update

Thanks for the contribution. Clownfish hit a branch-permission wall on this PR, so it opened a replacement branch to keep review moving while preserving credit.

Replacement PR: #93441
Source PR: #65301
This source PR remains open; the replacement is just the writable fix lane.
The replacement PR carries the original credit trail forward.

fish notes: model gpt-5.5, reasoning medium; reviewed against 4d9329c.

ClawSweeper applied the proposed close for this PR.

• Action: closed this PR.
• Close reason: mostly implemented on main.
• Evidence: durable ClawSweeper review.