`message.send` should only reject for poll creation when poll creation intent is actually present, e.g.: - non-empty `pollQuestion` - non-empty `pollOption` - maybe positive poll duration values - explicit poll-only fields that meaningfully indicate a poll request But `0` alone should not flip send into poll mode.

openclaw - ✅(Solved) Fix [Bug]: message send attachment/file replies can fail when zero-valued poll params are present [2 pull requests, 3 comments, 3 participants]

openclaw2026-03-22 06:53:46

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#52118•Fetched 2026-04-08 01:15:23

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×3cross-referenced ×2closed ×1locked ×1

Error Message

This blocked a normal Telegram attachment send in a real agent session and produced a confusing error message unrelated to the requested action.

Root Cause

A message.send call that includes normal send/attachment params but also includes poll-related numeric fields set to zero (for example because the tool schema/client provides numeric defaults):

Fix Action

Fixed

Fixed by PR: fix(message): ignore zero-valued poll defaults in send path (https://github.com/openclaw/openclaw/pull/52141)
Fixed by PR: fix(poll-params): treat zero-valued numeric poll params as unset (https://github.com/openclaw/openclaw/pull/52150)

PR fix notes

PR #52141: fix(message): ignore zero-valued poll defaults in send path

Repository: openclaw/openclaw
Author: ningfeemic-dev
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/52141

Description (problem / solution / changelog)

Fixes #52118.

Summary

treat zero-valued numeric poll params as unset in hasPollCreationParams()
keep non-zero numeric poll params as poll intent
add regression coverage for message.send with zero-valued poll defaults present

Why

message.send currently rejects normal send/file operations when callers include poll numeric defaults like:

pollDurationHours: 0
pollDurationSeconds: 0

Those zero values are currently interpreted as poll creation intent, which is too broad for send-path validation.

Changes

src/poll-params.ts
- numeric poll params now count as poll intent only when non-zero
src/poll-params.test.ts
- update helper expectations for 0 / "0"
src/infra/outbound/message-action-runner.plugin-dispatch.test.ts
- add regression test proving send still uses the send path when zero-valued poll defaults are present

Validation

Ran targeted tests:

src/poll-params.test.ts
src/infra/outbound/message-action-runner.plugin-dispatch.test.ts

Both passed locally.

Related: #48928 #51830 #48870 #48730 #42820 #43015

Changed files

src/infra/outbound/message-action-runner.plugin-dispatch.test.ts (modified, +60/-0)
src/poll-params.test.ts (modified, +5/-2)
src/poll-params.ts (modified, +6/-3)

PR #52150: fix(poll-params): treat zero-valued numeric poll params as unset

Repository: openclaw/openclaw
Author: Bartok9
State: closed | merged: True
Link: https://github.com/openclaw/openclaw/pull/52150

Description (problem / solution / changelog)

Summary

Fixes #52118

References #52141

Zero values (pollDurationHours: 0, pollDurationSeconds: 0, etc.) are typically defaults/unset values from tool schemas, not intentional poll creation requests.

Previously, any finite number including 0 was treated as poll creation intent, causing normal message.send calls to fail with:

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

This was observed when callers included zero-valued numeric defaults (for example from serialized schemas).

This PR keeps zero-valued poll params treated as unset for normal sends, while preserving the existing behavior that non-zero poll params still count as poll intent. That means invalid negative durations continue to hit the poll-only validation path instead of being silently ignored.

Changes

Updated hasPollCreationParams() so zero-valued numeric poll params are treated as unset/defaults during message.send
Preserved the non-zero poll-intent behavior so invalid negative durations still route through the poll validation path
Added explicit tests for zero-valued poll params on both the helper and send path
Added a regression test showing negative poll durations still fail on the poll-only guard path

Testing

pnpm test -- src/poll-params.test.ts src/infra/outbound/message-action-runner.context.test.ts src/infra/outbound/message-action-runner.plugin-dispatch.test.ts
pnpm tsgo
pnpm check

Changed files

CHANGELOG.md (modified, +1/-0)
src/infra/outbound/message-action-runner.context.test.ts (modified, +9/-0)
src/infra/outbound/message-action-runner.plugin-dispatch.test.ts (modified, +60/-0)
src/poll-params.test.ts (modified, +13/-2)
src/poll-params.ts (modified, +6/-2)

RAW_BUFFERClick to expand / collapse

Problem

Using the message tool with action="send" can fail with:

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

This happens even when the caller is not trying to create a poll.

Repro shape

A message.send call that includes normal send/attachment params but also includes poll-related numeric fields set to zero (for example because the tool schema/client provides numeric defaults):

pollDurationHours: 0
pollDurationSeconds: 0
possibly other poll fields present but logically unset

Observed result:

action="send"
intended behavior: normal message/file send
actual behavior: rejected as if it were a poll creation request

Root cause (code inspection)

In the built code, hasPollCreationParams(params) treats any finite number in poll params as poll intent:

POLL_CREATION_PARAM_DEFS includes pollDurationHours, pollDurationSeconds, etc.
hasPollCreationParams returns true when a number field is any finite number
therefore 0 is treated as poll creation intent

Relevant path seen locally in built output:

dist/reply-Bm8VrLQh.js

Behavior chain:

message.send receives params
if (action === "send" && hasPollCreationParams(params)) throw ...
zero-valued poll duration fields trigger hasPollCreationParams
ordinary send is rejected

Why this is a bug

0 here is effectively an unset/default value in many callers/tool schemas, not an affirmative request to create a poll.

This makes message.send brittle whenever the caller serializes a full schema object or includes numeric defaults.

Expected behavior

message.send should only reject for poll creation when poll creation intent is actually present, e.g.:

non-empty pollQuestion
non-empty pollOption
maybe positive poll duration values
explicit poll-only fields that meaningfully indicate a poll request

But 0 alone should not flip send into poll mode.

Possible fixes

Option A: tighten `hasPollCreationParams`

For numeric poll fields, only treat values as poll intent if they are meaningfully set (e.g. > 0) instead of any finite number.

Option B: require semantic poll intent

Only consider it a poll creation request if required poll fields are present, especially:

pollQuestion
at least one/two pollOption

Option C: sanitize default-zero params before send validation

If the tool schema/client emits zero defaults, strip poll params that are effectively unset before running poll validation.

User impact

This blocked a normal Telegram attachment send in a real agent session and produced a confusing error message unrelated to the requested action.

Environment

Observed on OpenClaw main install under /usr/lib/node_modules/openclaw with current built dist bundle on 2026-03-22.

extent analysis

Fix Plan

To resolve the issue, we will implement Option A: tighten hasPollCreationParams. This involves modifying the hasPollCreationParams function to only consider numeric poll fields as poll intent if their values are greater than 0.

Step-by-Step Solution

Locate the hasPollCreationParams function in the dist/reply-Bm8VrLQh.js file.
Update the condition for numeric poll fields to check if the value is greater than 0:

const hasPollCreationParams = (params) => {
  // ...
  if (params.pollDurationHours > 0 || params.pollDurationSeconds > 0) {
    return true;
  }
  // ...
}

Alternatively, you can use a more concise approach:

const hasPollCreationParams = (params) => {
  // ...
  const pollFields = ['pollDurationHours', 'pollDurationSeconds'];
  return pollFields.some((field) => params[field] > 0);
  // ...
}

Save the changes and rebuild the dist bundle.

Verification

To verify that the fix worked, test the message.send function with a payload that includes zero-valued poll duration fields. The function should no longer reject the request as a poll creation attempt.

Extra Tips

Consider adding input validation to ensure that numeric poll fields are not negative.
Review the tool schema/client to ensure that it is not emitting unnecessary default values for poll fields.
Test the message.send function with various payloads to ensure that it behaves as expected in different scenarios.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

message.send should only reject for poll creation when poll creation intent is actually present, e.g.:

non-empty pollQuestion
non-empty pollOption
maybe positive poll duration values
explicit poll-only fields that meaningfully indicate a poll request

But 0 alone should not flip send into poll mode.

#GPU setup #container setup #orchestration issue #cache issue #memory leak

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: message send attachment/file replies can fail when zero-valued poll params are present [2 pull requests, 3 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fixed

PR fix notes

PR #52141: fix(message): ignore zero-valued poll defaults in send path

Description (problem / solution / changelog)

Summary

Why

Changes

Validation

Related

Changed files

PR #52150: fix(poll-params): treat zero-valued numeric poll params as unset

Description (problem / solution / changelog)

Summary

Changes

Testing

Changed files

Problem

Repro shape

Root cause (code inspection)

Why this is a bug

Expected behavior

Possible fixes

Option A: tighten hasPollCreationParams

Option B: require semantic poll intent

Option C: sanitize default-zero params before send validation

User impact

Environment

extent analysis

Fix Plan

Step-by-Step Solution

Verification

Extra Tips

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING

Option A: tighten `hasPollCreationParams`