Repository navigation
perf(cron): reuse normalized history projection - #140170
Merged
Merged
Conversation
Contributor
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
steipete
marked this pull request as ready for review
September 6, 2026 14:32
Contributor
|
Codex review: needs maintainer review before merge. Reviewed September 6, 2026, 10:39 AM ET / 14:39 UTC. ClawSweeper reviewWhat this changesReduces automation-history processing overhead by reusing the normalized result and expands coverage for status normalization, immutable inputs, and legacy optional fields. Merge readiness✅ Ready for maintainer review The optimization remains useful: fetched main and the latest release retain the redundant work. No actionable correctness or security defect was found, and this maintainer-authored PR is protected from automatic closure. Priority: P2 Review scores
Verification
How this fits togetherAutomation history reads stored task records from SQLite and converts them into run-history responses. The same conversion also supplies stored outcomes to execution recovery. flowchart LR
A[Stored task records] --> B[History reader]
B --> C[Normalize and allowlist fields]
C --> D[Materialize legacy optional fields]
D --> E[Filter and paginate history]
E --> F[CLI and Gateway responses]
C --> G[Stored outcome recovery]
Before mergeNone. Agent review detailsSecurityNone. PR surfaceSource -2, Tests +13. Total +11 across 2 files. View PR surface stats
Review metrics
Technical reviewBest possible solution: Keep one status-normalization path and reuse its private result while preserving the existing history and recovery contracts. Do we have a high-confidence way to reproduce the issue? Not applicable as a functional bug reproduction: this is a performance optimization, supported by source-visible redundant work and reported baseline/candidate benchmarks. Is this the best way to solve the issue? Yes. Reusing the existing normalizer and its fresh result is a narrow solution that preserves field exclusion, input immutability, and legacy output properties. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against b5b64a8d5133. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
Contributor
Author
|
Merged via squash.
|
github-actions Bot
pushed a commit
to Desicool/openclaw
that referenced
this pull request
Sep 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Problem This Solves
Automation history requests incur avoidable per-record overhead as the number of stored runs grows.
Why This Change Was Made
Use the existing full schema as the single status normalizer, then materialize the five legacy optional fields on its private result instead of copying it again. Input tasks, field exclusion and insertion order, authored-detail precedence, recovery decisions, and all database/configuration/concurrency behavior remain unchanged. Production −2 lines; the existing wire-record test expands by 13 lines.
User Impact
Synthetic 50/500/2,000-record projector batches improved 45–57% in both orders. The real history-page caller, including SQLite reading/hydration, improved in 23 of 24 nonempty comparisons; the remaining 2,000-row ascending case was 4.06% slower forward and 33.84% faster reverse. This does not claim faster whole-Gateway turns or a consistent memory reduction.
Evidence
ce7eb85ae413282d0d46b2b661d11788d5fde671: 20 rows per phase, three warm calls and 12 fixed samples per row. All 5,040 full wrapper returns (240 warm + 4,800 timed) matched, including undefined-valued own fields, insertion order, and reference graph. No retries or favorable subset selection.Across the same 12 sample means per row, 7/40 mean comparisons and 8/40 maximum comparisons were slower. These are maxima of observed sample means, not population-tail estimates. Notable adverse observations: 50-row descending history maxima +5.45%/+4.87%; 2,000-row descending history forward maximum +40.37%; empty status-filtered history means +56.77%/+51.58% and maxima +367.77%/+370.99%. Every underlying sample remains retained.
Full-process wall improved 12.83%/11.32%, but includes imports, fixture creation, assertions and evidence writing. Forward kernel/sample-tree RSS rose 0.88%/1.10%; system CPU rose 8.85%/10.25% across the two orders. No memory or whole-Gateway improvement is claimed. All children closed and the exact candidate was restored. Independent retained-data audit passed: it decoded all 5,040 returns from 115,009,918 bytes, verified every journal ordinal and timing sum, and independently checked complete values, own-key order and bidirectional reference relationships.