fix(discord): inherit forum default_auto_archive_duration for thread creation by tzy-17 · Pull Request #103033 · openclaw/openclaw

tzy-17 · 2026-07-09T17:40:33Z

What Problem This Solves

Fixes #103021: Discord forum/media threads created by message action=send ignored the parent channel's default_auto_archive_duration. When the field was omitted from the thread-create request, Discord used 4320 minutes instead of the operator's configured value such as 1440 minutes.

Why This Change Was Made

The reported send path does not call createThreadDiscord; it calls sendMessageDiscord, which fetched the target channel only to classify its numeric type and then built the forum thread request directly in send.outbound.ts.

The revised fix carries that existing lookup forward as a typed Discord channel. Once narrowed to a forum/media parent, the send path copies its default_auto_archive_duration into the same thread-create request. This avoids another API request, preserves the field-absent fallback, and leaves the explicit thread-create action and its autoArchiveMinutes override unchanged.

User Impact

Implicit forum/media posts now use the parent channel's configured archive duration.
Non-forum sends and component handling retain their existing behavior.
The explicit thread-create action remains unchanged.
No new config, environment variable, or message-tool parameter is introduced.

Evidence

Exact reviewed head: fcb7c056d7b8bd4489e6565eef3a8c83abd889d2.
Blacksmith Testbox through Crabbox tbx_01kx4hyrjn05y5r8ttcn8sykfh: 206/206 focused Discord tests passed across the production send, explicit thread-create, component, and action-runtime surfaces.
pnpm check:changed: extension production/test typechecks, lint, dependency/architecture guards, and runtime import-cycle checks passed.
Fresh Codex autoreview: no accepted/actionable findings; patch correct at 0.87 confidence.
Discord's channel resource contract exposes default_auto_archive_duration and accepts auto_archive_duration on forum/media thread creation; the pinned [email protected] types match that contract.
Live create/read-back was not run because neither the dedicated Testbox nor the maintainer checkout exposed an authorized Discord smoke credential/account. The linked issue supplies the shipped live 4320-minute symptom; the regression test proves the corrected 1440-minute request body.

Thanks @tzy-17 for the report-linked fix and contribution.

clawsweeper · 2026-07-09T17:42:33Z

Codex review: needs real behavior proof before merge. Reviewed July 9, 2026, 2:49 PM ET / 18:49 UTC.

Summary
The PR changes Discord's createThreadDiscord helper to copy a forum/media channel default archive duration into route-less thread creation payloads when no explicit archive duration is set.

PR surface: Source +28. Total +28 across 1 file.

Reproducibility: yes. at source level: message action=send reaches sendMessageDiscord, whose forum/media branch still sends a create-thread body without auto_archive_duration. I did not run a live Discord token repro in this read-only pass.

Review metrics: none identified.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #103021
Summary: This PR is intended as the candidate fix for the linked Discord forum archive-duration issue, but the current diff does not yet fix the central action=send path.

Members:

canonical: Bug: Discord forum threads created via the message tool ignore the forum's default_auto_archive_duration (always 4320 / 3 days) #103021 - The PR body uses closing syntax for this issue, and the issue describes the same Discord forum archive-duration behavior.

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

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🧂 unranked krab
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Move or share the inheritance logic into sendMessageDiscord's forum/media branch.
[P1] Add focused regression coverage for forum/media sends inheriting the parent default while explicit thread creation preserves overrides.
Provide redacted live Discord proof or logs showing the created thread has the expected archive duration.

Proof guidance:

[P1] Needs real behavior proof before merge: The PR body cites unit tests only; before merge, add redacted live Discord output, logs, or a transcript showing the created thread's archive duration, then update the PR body for automatic re-review or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

[P1] If merged as-is, the linked action=send forum-parent bug remains because the actual forum send branch is unchanged.
[P1] No real Discord proof has been posted, so the PR does not yet show the created thread's archive duration from a live server response.

Maintainer options:

Decide the mitigation before merge
Apply the inherit-default logic in sendMessageDiscord's forum/media branch, or a shared helper used by that branch, with regression coverage for forum sends and explicit thread creation.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

[P1] Contributor revision and real Discord proof are required; ClawSweeper should not take a repair lane while contributor-owned proof is absent.

Security
Cleared: No security or supply-chain concern was found in this single-file Discord runtime change.

Review findings

[P1] Patch the actual forum send path — extensions/discord/src/send.messages.ts:177-181

Review details

Best possible solution:

Apply the inherit-default logic in sendMessageDiscord's forum/media branch, or a shared helper used by that branch, with regression coverage for forum sends and explicit thread creation.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: message action=send reaches sendMessageDiscord, whose forum/media branch still sends a create-thread body without auto_archive_duration. I did not run a live Discord token repro in this read-only pass.

Is this the best way to solve the issue?

No as submitted: inheriting the forum default is the right fix shape, but the implementation must cover the actual forum-parent send path rather than only createThreadDiscord.

Full review comments:

[P1] Patch the actual forum send path — extensions/discord/src/send.messages.ts:177-181
This previous blocker still applies. The new code only changes createThreadDiscord, but the reported message action=send flow calls sendMessageDiscord, whose forum/media branch still creates the thread with only name and message. As a result, forum-parent sends still omit auto_archive_duration; move or share the inheritance logic with that branch.
Confidence: 0.95

Overall correctness: patch is incorrect
Overall confidence: 0.94

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 8656c3b357f6.

Label changes

Label justifications:

P2: This is a focused Discord channel bug-fix PR with limited blast radius, but the current patch still misses the reported send path and needs revision before merge.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body cites unit tests only; before merge, add redacted live Discord output, logs, or a transcript showing the created thread's archive duration, then update the PR body for automatic re-review or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

PR surface:

Source +28. Total +28 across 1 file.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	54	26	+28
Tests	0	0	0	0
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	1	54	26	+28

What I checked:

Changed helper only: At PR head, the new default-inheritance logic is added inside createThreadDiscord for route-less thread creation. (extensions/discord/src/send.messages.ts:177, 0e7cbe9fb8ee)
Reported entry point bypasses helper: The Discord message action dispatches normal sends to sendMessageDiscord, not createThreadDiscord, so the reported message action=send flow is outside the changed helper. (extensions/discord/src/actions/runtime.messaging.send.ts:300, 8656c3b357f6)
PR head leaves forum send body unchanged: At PR head, sendMessageDiscord still creates forum/media threads with a body containing name and message only, with no auto_archive_duration. (extensions/discord/src/send.outbound.ts:237, 0e7cbe9fb8ee)
Current main source behavior: Current main has the same forum/media send branch shape: it calls createThread with name and nested message, but no archive-duration field. (extensions/discord/src/send.outbound.ts:237, 8656c3b357f6)
Existing regression target: The existing forum-send test asserts the create-thread body exactly as { name, message }, matching the omitted archive-duration behavior that needs regression coverage. (extensions/discord/src/send.sends-basic-channel-messages.test.ts:454, 8656c3b357f6)
Linked canonical issue: Live GitHub data shows this PR closes Bug: Discord forum threads created via the message tool ignore the forum's default_auto_archive_duration (always 4320 / 3 days) #103021, which reports the same Discord forum archive-duration bug for message action=send. (0e7cbe9fb8ee)

Likely related people:

steipete: GitHub path history shows repeated recent Discord send/action maintenance near send.outbound.ts, send.messages.ts, and runtime action surfaces. (role: recent area contributor; confidence: high; commits: bfb89d3ea653, 41810a462e3c, 95331e5cc52d; files: extensions/discord/src/send.outbound.ts, extensions/discord/src/send.messages.ts, extensions/discord/src/actions/runtime.messaging.send.ts)
joshavant: Recent Discord outbound work changed thread-name and bare-channel send behavior in the same send/action area. (role: recent adjacent contributor; confidence: medium; commits: c5b987274ae9, bcbf4fc35f8a; files: extensions/discord/src/send.outbound.ts, extensions/discord/src/actions/runtime.messaging.send.ts)
scoootscooob: Moved the Discord implementation into extensions/discord/src, establishing the current plugin boundary and preserving the involved send/action files. (role: feature-history mover; confidence: medium; commits: 5682ec37fada; files: extensions/discord/src/send.outbound.ts, extensions/discord/src/send.messages.ts, extensions/discord/src/actions/runtime.messaging.send.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (2 earlier review cycles)

reviewed 2026-07-09T17:48:16.356Z sha 108ada7 :: needs real behavior proof before merge. :: [P1] Patch the actual forum send path | [P2] Narrow the channel before reading forum defaults
reviewed 2026-07-09T18:42:28.203Z sha 0e7cbe9 :: needs real behavior proof before merge. :: [P1] Patch the actual forum send path

Carry typed forum/media parent metadata through the message-send path so implicit thread creation uses the configured default archive duration. Co-authored-by: 唐梓夷0668001293 <[email protected]>

steipete · 2026-07-09T23:23:16Z

Land-ready review completed on exact head fcb7c056d7b8bd4489e6565eef3a8c83abd889d2.

What changed:

Rewrote the patch at the actual message action=send boundary: sendMessageDiscord now carries the typed parent-channel lookup forward and copies a forum/media parent's default_auto_archive_duration into the implicit thread-create request.
Preserved the field-absent fallback, normal channel sends, component behavior, and the explicit thread-create/autoArchiveMinutes sibling path.
Added production-path regression coverage for a 1440-minute forum default. The maintainer rewrite preserves @tzy-17's contributor credit.

Proof:

Blacksmith Testbox through Crabbox tbx_01kx4hyrjn05y5r8ttcn8sykfh: 206/206 focused Discord tests passed across send.sends-basic-channel-messages, send.creates-thread, send.components, and actions/runtime.
The same Testbox ran pnpm check:changed; extension source/test typechecks, lint (0 warnings/errors), dependency/architecture guards, database-first checks, and runtime import-cycle checks passed.
Exact-head CI: https://github.com/openclaw/openclaw/actions/runs/29056811522
Fresh Codex autoreview: no accepted/actionable findings; patch correct at confidence 0.87.
Dependency contract checked against Discord's channel resource documentation and the pinned [email protected] source/types.

Known proof gap: no authorized Discord smoke credential or configured Discord account was available in the dedicated Testbox or maintainer checkout, so I could not run a live create/read-back. The linked issue supplies the shipped live 4320-minute symptom; the focused production-path test proves the corrected request carries 1440.

steipete · 2026-07-09T23:23:38Z

Merged via squash.

Prepared head SHA: fcb7c056d7b8bd4489e6565eef3a8c83abd889d2
Landed commit: 3dd5c1880f46f3ed2f7a4fac40db6f3e5f88eac9

Carry typed forum/media parent metadata through the message-send path so implicit thread creation uses the configured default archive duration. Co-authored-by: Peter Steinberger <[email protected]>

…scord When createThreadForBinding hardcoded autoArchiveMinutes: 60, the parent channel's default_auto_archive_duration (configured by operators at 1440, 4320, or 10080) was silently overridden. This is the same pattern fixed in openclaw#103033 for sendMessageDiscord's implicit forum thread creation. - Move the auto_archive_duration set after the channel fetch in createThreadDiscord so channel.default_auto_archive_duration can serve as a fallback when autoArchiveMinutes is not provided. - Remove the hardcoded autoArchiveMinutes: 60 from createThreadForBinding so it inherits the channel default for forum/media channels and omits the field for text channels (preserving Discord's server-side default). - Explicit autoArchiveMinutes from callers (thread-create action, auto-thread config) still take priority via the ?? operator. Co-Authored-By: Claude <[email protected]>

…scord (#103413) * fix(discord): inherit default_auto_archive_duration in createThreadDiscord When createThreadForBinding hardcoded autoArchiveMinutes: 60, the parent channel's default_auto_archive_duration (configured by operators at 1440, 4320, or 10080) was silently overridden. This is the same pattern fixed in #103033 for sendMessageDiscord's implicit forum thread creation. - Move the auto_archive_duration set after the channel fetch in createThreadDiscord so channel.default_auto_archive_duration can serve as a fallback when autoArchiveMinutes is not provided. - Remove the hardcoded autoArchiveMinutes: 60 from createThreadForBinding so it inherits the channel default for forum/media channels and omits the field for text channels (preserving Discord's server-side default). - Explicit autoArchiveMinutes from callers (thread-create action, auto-thread config) still take priority via the ?? operator. Co-Authored-By: Claude <[email protected]> * refactor(discord): preserve parent thread archive defaults Co-authored-by: 陈志强0668000989 <[email protected]> * docs(changelog): credit Discord archive default fix Co-authored-by: 陈志强0668000989 <[email protected]> --------- Co-authored-by: Claude <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

…scord (openclaw#103413) * fix(discord): inherit default_auto_archive_duration in createThreadDiscord When createThreadForBinding hardcoded autoArchiveMinutes: 60, the parent channel's default_auto_archive_duration (configured by operators at 1440, 4320, or 10080) was silently overridden. This is the same pattern fixed in openclaw#103033 for sendMessageDiscord's implicit forum thread creation. - Move the auto_archive_duration set after the channel fetch in createThreadDiscord so channel.default_auto_archive_duration can serve as a fallback when autoArchiveMinutes is not provided. - Remove the hardcoded autoArchiveMinutes: 60 from createThreadForBinding so it inherits the channel default for forum/media channels and omits the field for text channels (preserving Discord's server-side default). - Explicit autoArchiveMinutes from callers (thread-create action, auto-thread config) still take priority via the ?? operator. Co-Authored-By: Claude <[email protected]> * refactor(discord): preserve parent thread archive defaults Co-authored-by: 陈志强0668000989 <[email protected]> * docs(changelog): credit Discord archive default fix Co-authored-by: 陈志强0668000989 <[email protected]> --------- Co-authored-by: Claude <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

openclaw-barnacle Bot added channel: discord Channel integration: discord size: S labels Jul 9, 2026

steipete self-assigned this Jul 9, 2026

fix(discord): honor forum archive defaults

fcb7c05

Carry typed forum/media parent metadata through the message-send path so implicit thread creation uses the configured default archive duration. Co-authored-by: 唐梓夷0668001293 <[email protected]>

steipete force-pushed the fix/103021-discord-forum-archive-duration branch from 0e7cbe9 to fcb7c05 Compare July 9, 2026 23:13

openclaw-barnacle Bot added size: XS and removed size: S labels Jul 9, 2026

steipete merged commit 3dd5c18 into openclaw:main Jul 9, 2026
105 of 107 checks passed

steipete mentioned this pull request Jul 9, 2026

Bug: Discord forum threads created via the message tool ignore the forum's default_auto_archive_duration (always 4320 / 3 days) #103021

Closed

github-actions Bot mentioned this pull request Jul 10, 2026

📡 Upstream Digest — 2026-07-10 02:07 UTC curtismercier/openclaw-mods#1248

Open

wings1029 mentioned this pull request Jul 10, 2026

fix(discord): inherit default_auto_archive_duration in createThreadDiscord #103413

Merged

clawsweeper Bot mentioned this pull request Jul 10, 2026

fix(discord): inherit forum auto archive duration #103179

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(discord): inherit forum default_auto_archive_duration for thread creation#103033

fix(discord): inherit forum default_auto_archive_duration for thread creation#103033
steipete merged 1 commit into
openclaw:mainfrom
tzy-17:fix/103021-discord-forum-archive-duration

tzy-17 commented Jul 9, 2026 •

edited by steipete

Loading

Uh oh!

clawsweeper Bot commented Jul 9, 2026 •

edited

Loading

Uh oh!

steipete commented Jul 9, 2026

Uh oh!

Uh oh!

steipete commented Jul 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

tzy-17 commented Jul 9, 2026 • edited by steipete Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

clawsweeper Bot commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steipete commented Jul 9, 2026

Uh oh!

Uh oh!

steipete commented Jul 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tzy-17 commented Jul 9, 2026 •

edited by steipete

Loading

clawsweeper Bot commented Jul 9, 2026 •

edited

Loading