feat(outbox): migrate delivery queue from file-based to SQLite outbox#29147
feat(outbox): migrate delivery queue from file-based to SQLite outbox#29147nohat wants to merge 1 commit intoopenclaw:mainfrom
Conversation
Replace unbounded file-based delivery queue with queryable SQLite message_outbox table. Adds TTL/expiry for stale entries, delivery outcome retention, and one-time legacy file queue import on startup. Closes openclaw#23777, openclaw#16555, openclaw#29128
Greptile SummaryMigrated outbound delivery queue from file-based JSON to SQLite with proper retry/expiry semantics. The implementation is solid and production-ready. Key Changes:
Test Coverage:
Architecture:
No issues found — implementation is clean, well-tested, and follows project conventions. Confidence Score: 5/5
Last reviewed commit: bc93966 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bc9396655f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| await recoverPendingDeliveries({ | ||
| deliver: deliverOutboundPayloads, |
There was a problem hiding this comment.
Run outbox pruning in gateway maintenance loop
This startup flow imports legacy files and runs recovery, but it never invokes pruneOutbox; after this commit ackDelivery keeps successful sends as delivered rows instead of removing them. In production gateways with steady traffic, message_outbox will grow without bound, which will eventually slow recovery/startup queries and inflate message-lifecycle.db indefinitely.
Useful? React with 👍 / 👎.
bc93966 to
75fc0d3
Compare
|
Superseded by fresh PR stack — links to follow. |
|
New PR stack:
|
Summary
message_outboxtable; added configurable TTL/expiry (messages.delivery.maxAgeMs,messages.delivery.expireAction); one-time migration imports existing file-queue entries; exponential backoff for retries (5s → 25s → 2m → 10m, max 5)Change Type (select all)
Scope (select all touched areas)
Linked Issue/PR
User-visible / Behavior Changes
messages.delivery.maxAgeMs(default 30m),messages.delivery.expireAction("fail"or"deliver")delivery-queue/*.jsonfiles tomessage-lifecycle.dbSQLite database on first startup (automatic, one-time migration)Security Impact (required)
Repro + Verification
Environment
messages.delivery.maxAgeMs,messages.delivery.expireActionSteps
maxAgeMsExpected
Actual
Evidence
Human Verification (required)
pnpm build,pnpm test(948 pass),pnpm checkCompatibility / Migration
messages.deliveryconfig keys (defaults preserve existing behavior)Failure Recovery (if this breaks)
node:sqliteunavailable on older Node versions (requires Node 22+); in-memory fallback means entries don't persist across restartsRisks and Mitigations
node:sqlitenot available on some Node versionsE2E Test Results
Tested with live Telegram bot on
lifecycle/sqlite-outboxbranch:delivery-queue/*.jsonfiles migrated tomessage_outboxSQLite table on first startup, JSON files removedfailed_terminal, fresh entries attempted and properly failed with backoffE2E test script: https://gist.github.com/nohat/d9d7b076c760b178cdfbf589242c0788