Repository navigation
Published archive: message text empty since 2026-10-09, and text repair overwrote existing text with empty content #321
Description
Summary
Since about 2026-10-09 18:00 UTC, every new human message in the OpenClaw guild's published git-share archive has content = "" and text_parts_json = [].
Separately, on 2026-10-26 16:41–16:49 UTC (with a few rows on Oct 23 and 25), about 2,100 older rows were rewritten to text_version = 2 with empty text. Many of those rows had text in earlier share commits.
The same messages read through a bot that has message-content access do return their text. Two problems seem to be combined:
- The publisher appears to have lost message-content access. This is operational, but discrawl published empty rows without any warning.
- Text repair replaced existing non-empty text with an empty re-read, which loses data in the archive.
Evidence
Observed from a share subscriber running discrawl 0.17.0. Aggregates only. Scope: OpenClaw guild, non-bot authors, message_type 0 or 19.
New messages captured empty. In rows still at text_version = 0 (never rewritten), the empty rate is normal until Oct 9 17:00 UTC, then becomes total:
| Hour (UTC) | Rows | Empty |
|---|---|---|
| 2026-10-09 17:00 | 77 | 7 |
| 2026-10-09 18:00 | 43 | 43 |
| Every hour after that, through 2026-10-27 03:00 | all | all |
Before that, normal. From Sep 24 to 30, 0–3 rows per day out of roughly 1,000–2,000 were empty, after excluding rows with attachments, stickers or embeds.
Existing text overwritten.
- There are 2,123 rows created in October 2026 with
text_version = 2, across 53 channels. Of these, 2,027 have emptycontentandtext_parts_json = []. - Their
updated_atvalues fall between 2026-10-23T16:55Z and 2026-10-26T16:49Z. 2,188 of the 2,197text_version = 2rows created before Oct 10 were updated on Oct 26. - I sampled 300 of these rows: human, created Oct 1–8, no attachments.
- In share commit
8aa145b(2026-10-21T23:13Z), 297 of the 300 were present and 268 had non-emptycontent. - In share HEAD
8054648(2026-10-27T03:22Z), all 300 are empty, attext_version = 2, and updated 2026-10-26 16:41–16:49 UTC.
- In share commit
Likely causes (unconfirmed)
- Lost content access. Around 2026-10-09 18:00 UTC, the publishing bot most likely lost Discord's privileged MESSAGE_CONTENT access, for example through the intent toggle, a token or app change, or its config. Without it, Discord returns empty
contentto both Gateway and REST, which matches every new row being empty. - Repair trusts empty re-reads. The 2026-10-26 rewrite looks like text repair or re-read (resumable text repair shipped in v0.17.0) running under the same missing access. It accepted an empty re-read as authoritative and replaced stored text.
Expected behavior
- Repair or re-read should never replace non-empty stored text with empty content when nothing else indicates the message changed (for example,
edited_atis unchanged and attachments, embeds and components are unchanged). At minimum, it should refuse when the read lacks content access. - Sync,
doctoror status should flag missing message-content access, for example when every non-bot message in a batch arrives with empty content, rather than silently publishing empty rows.
Recovery notes
- Rows rewritten on Oct 23–26 can be restored from earlier share commits (for example
8aa145b). - Messages first captured after 2026-10-09 18:00 UTC were never archived with text. They need a re-read once content access is restored on the publisher.
Activity
clawsweeper commentedon Oct 27, 2026
Codex review: this still needs some work.
Summary
Keep this issue open: v0.19.0 includes bounded overwrite protection, but publisher visibility, historical recovery, and the requested warning remain unresolved.
Reproducibility: The production incident was not reproduced; source confirms the released preservation boundary and missing visibility measurement, but private archive evidence and publisher access still require operator verification.
Root-cause cluster
Relationship:
canonicalCanonical: #321
Summary: This issue retains the broader incident scope; the preservation fix and diagnostic proposal address separate parts without establishing recovery.
Members:
partial_overlap: fix: preserve authored text on ambiguous empty rereads #325 - Released protection prevents a bounded overwrite path but does not restore historical text or verify initial capture visibility.partial_overlap: Add admitted read-only Discord content diagnostic #323 - The held diagnostic supports access investigation without implementing archive recovery or a general warning.Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.
Maintainer decision needed
Next step
Complete the existing operator visibility handoff, assign archive recovery ownership, and decide Doctor warning semantics while preserving the diagnostic hold.
Review details
Best possible solution:
Verify publisher visibility, restore recoverable text with backup and sample validation, and provide an actionable Doctor warning for suspected missing content.
Do we have a high-confidence way to reproduce the issue?
The production incident was not reproduced; source confirms the released preservation boundary and missing visibility measurement, but private archive evidence and publisher access still require operator verification.
Is this the best way to solve the issue?
The released guard addresses the bounded overwrite case; remaining work should follow the existing operator handoff and an agreed warning policy rather than assume derived text repair caused canonical loss.
AGENTS.md: found but not applied because it conflicted with ClawSweeper's review contract.
Remaining risk / open question:
Codex review notes: model internal, reasoning medium; reviewed against 4ea7d52ed6f8.
Label changes
Label changes:
No label changes.
Label justifications:
P0: The report documents widespread archive text loss and empty subsequent captures, with present publisher health and recovery still unverified.impact:data-loss: Previously populated archive rows reportedly became empty, and later messages were published without authored text.Evidence reviewed
What I checked:
AGENTS.md:3, 4ea7d52ed6f8)internal/store/write.go:663, b68eb958a1e5)internal/syncer/empty_snapshot_test.go:179, 4ea7d52ed6f8)internal/store/text_repair.go:105, 4ea7d52ed6f8)internal/cli/admin_commands.go:662, 4ea7d52ed6f8)Likely related people:
internal/store/text_repair.go)How this review workflow works
@clawsweeper re-reviewcomments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.@clawsweeper re-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only.@clawsweeper reviewto request a fresh review only.@clawsweeper explainto ask for more context, or@clawsweeper stopto stop active automation.Reviewed November 2, 2026, 2:20 PM ET / 19:20 UTC.
281 remaining items