Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Cron delivery schema rejects threadId field present in TypeScript types — type/API schema drift [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
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.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73017•Fetched 2026-04-28 06:28:36
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
coachsootzcoachsootz
Participants
coachsootzcoachsootzsteipetesteipete
Timeline (top)
labeled ×2closed ×1commented ×1cross-referenced ×1

When passing threadId in a cron job's delivery object, the field is rejected at schema validation. ConfigDeliveryContextSchema (used elsewhere) does include threadId, but all three CronDelivery variant schemas do not — creating drift where valid-looking config silently fails. The TypeScript types in types.d.ts declare threadId, but the runtime API schema (CronDeliverySharedProperties + additionalProperties:false) does not. Result: no path to route cron deliveries to Telegram forum topics through the delivery layer.

Error Message

Schema validation rejects threadId. Error: "invalid cron.add params: at /delivery: unexpected property 'threadId'; at /delivery/mode: must be equal to constant; at /delivery: must match a schema in anyOf". CronDeliverySharedProperties does not include threadId, and all three delivery schemas (noop/announce/webhook) use additionalProperties:false. Meanwhile ConfigDeliveryContextSchema does declare threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])). Workaround: set delivery.mode="none" and call message tool explicitly inside payload — works but bypasses the delivery abstraction. Suggested fix: add threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])) to CronDeliverySharedProperties.

Root Cause

When passing threadId in a cron job's delivery object, the field is rejected at schema validation. ConfigDeliveryContextSchema (used elsewhere) does include threadId, but all three CronDelivery variant schemas do not — creating drift where valid-looking config silently fails. The TypeScript types in types.d.ts declare threadId, but the runtime API schema (CronDeliverySharedProperties + additionalProperties:false) does not. Result: no path to route cron deliveries to Telegram forum topics through the delivery layer.

Fix Action

Fix / Workaround

Schema validation rejects threadId. Error: "invalid cron.add params: at /delivery: unexpected property 'threadId'; at /delivery/mode: must be equal to constant; at /delivery: must match a schema in anyOf". CronDeliverySharedProperties does not include threadId, and all three delivery schemas (noop/announce/webhook) use additionalProperties:false. Meanwhile ConfigDeliveryContextSchema does declare threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])). Workaround: set delivery.mode="none" and call message tool explicitly inside payload — works but bypasses the delivery abstraction. Suggested fix: add threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])) to CronDeliverySharedProperties.

PR fix notes

PR #73025: fix(cron): accept delivery.threadId in protocol schema (#73017)

Description (problem / solution / changelog)

Fixes #73017.

Summary

The TypeScript types in `src/cron/types.ts` declare `threadId?: string | number` on every cron delivery shape (lines 29 and 53), and downstream code paths already plumb it through (`isolated-agent/run-executor.ts:160`, `channel-output-policy.ts:42`, etc.). But the runtime API schema in `src/gateway/protocol/schema/cron.ts` did not include `threadId` in `CronDeliverySharedProperties`, and every CronDelivery variant uses `additionalProperties: false`. Result: any cron job with `delivery.threadId` set was rejected at `cron.add` validation with `unexpected property 'threadId'` — locking out Telegram forum-topic routing through the delivery layer entirely.

Fix

Add to `CronDeliverySharedProperties`:

```ts threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])), ```

This propagates to all four call sites (the three CronDelivery* variants and `CronDeliveryPatchSchema`) via the existing spread. Mirrors the existing `ConfigDeliveryContextSchema` shape in `src/gateway/protocol/schema/config.ts:15` for consistency.

Tests

New focused schema test `src/gateway/protocol/cron.schema.test.ts` asserts:

  • `threadId: "topic-42"` accepted on `announce` delivery
  • `threadId: 42` accepted on `announce` delivery
  • `threadId` accepted on `none` and `webhook` variants too
  • Genuinely unexpected properties (e.g. `bogusField`) still rejected — `additionalProperties: false` invariant preserved.

``` Test Files 2 passed (cron.schema.test.ts: 4, channels.schema.test.ts: 1) Tests 8 passed (8) ```

Existing 3 `cron-protocol-conformance.test.ts` tests still pass.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/gateway/protocol/cron.schema.test.ts (added, +52/-0)
  • src/gateway/protocol/schema/cron.ts (modified, +7/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When passing threadId in a cron job's delivery object, the field is rejected at schema validation. ConfigDeliveryContextSchema (used elsewhere) does include threadId, but all three CronDelivery variant schemas do not — creating drift where valid-looking config silently fails. The TypeScript types in types.d.ts declare threadId, but the runtime API schema (CronDeliverySharedProperties + additionalProperties:false) does not. Result: no path to route cron deliveries to Telegram forum topics through the delivery layer.

Steps to reproduce

Create a cron job with delivery.mode = "announce" and delivery.threadId set to a Telegram topic thread ID:

{ "name": "example-job", "schedule": { "kind": "every", "everyMs": 3600000 }, "payload": { "kind": "systemEvent", "text": "heartbeat" }, "delivery": { "mode": "announce", "channel": "telegram", "to": "<chatId>", "threadId": "<topicThreadId>" } }

Expected behavior

Job created, announcements routed to the specified Telegram topic.

Actual behavior

Schema validation rejects threadId. Error: "invalid cron.add params: at /delivery: unexpected property 'threadId'; at /delivery/mode: must be equal to constant; at /delivery: must match a schema in anyOf". CronDeliverySharedProperties does not include threadId, and all three delivery schemas (noop/announce/webhook) use additionalProperties:false. Meanwhile ConfigDeliveryContextSchema does declare threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])). Workaround: set delivery.mode="none" and call message tool explicitly inside payload — works but bypasses the delivery abstraction. Suggested fix: add threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])) to CronDeliverySharedProperties.

OpenClaw version

2026.4.24 (cbcfdf6)

Operating system

macOS (Mac mini M4)

Install method

npm

Model

claude-sonnet-4-6, claude-opus-4-6, claude-haiku-4-5-20251001

Provider / routing chain

Anthropic (direct API)

Additional provider/model setup details

N/A — bug is in cron schema validation, not provider-related.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Add threadId to CronDeliverySharedProperties to fix schema validation rejection.

Guidance

  • Verify that the threadId field is indeed missing from the CronDeliverySharedProperties schema and that it is present in the ConfigDeliveryContextSchema.
  • Check the TypeScript types in types.d.ts to confirm that threadId is declared, but the runtime API schema does not include it.
  • Consider adding threadId: Type.Optional(Type.Union([Type.String(), Type.Number()])) to CronDeliverySharedProperties as a potential fix.
  • Test the workaround of setting delivery.mode="none" and calling the message tool explicitly inside the payload to confirm that it bypasses the delivery abstraction.

Example

No code snippet is provided as the issue is related to schema validation and not a specific code implementation.

Notes

The fix may require updating the schema definition to include the threadId field, which could have implications for other parts of the system.

Recommendation

Apply workaround: add threadId to CronDeliverySharedProperties to fix the schema validation rejection, as it is a targeted fix that addresses the specific issue.

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?
Loading…

FAQ

Expected behavior

Job created, announcements routed to the specified Telegram topic.

#api#LLM response#prompt template#agent execution#callback error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING