Maintenance tick parses each outstanding cleanup journal more than once
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 50/100
- Issue type
- Refactor
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript
- Domain
- performance
Research direction
Start by reading src/core/cache/purge-cleanup.js around line 180 and the maintenance paths in src/core/cache/maintenance.js cited in the issue. Trace how walkForRetired, sweepEvictedCacheCleanups, and the report path call readCacheCleanup, then identify how to measure calls within one tick. Done means a tick with several outstanding journals reads each at most once and the full suite passes.
Written by the indexing model from the issue text.
Description
Source: #2027 at 24be140b6ba1c9371564af4a1645bf85550e29ec
Location: src/core/cache/purge-cleanup.js:180; src/core/cache/maintenance.js:330 vs :445, :663, :2675, :2692
Severity: low
Evidence
sweepEvictedCacheCleanups re-reads and re-parses journals walkForRetired already parsed in the same tick, and readCacheCleanup is also called per partition in the report path. Confirmed at head 24be140b. Bounded by outstanding journals, which is zero in steady state; roughly 2 extra syscalls plus one JSON.parse per outstanding journal per tick.
Why deferral is safe
Efficiency only, with no incorrect behavior: the duplicate work is proportional to outstanding cleanups, not partitions or uptime, and threading a visited-id set out of a void-returning recursive walk is a wider change than the fix warranted.
Acceptance condition
One maintenance tick parses each outstanding journal at most once (for example a per-tick journal cache), demonstrated by counting readCacheCleanup calls in a tick with several outstanding journals, with the full suite green.
Review preference; backlog only. A human may explicitly delegate it with neutral:fix.
- Dominant language
- JavaScript
- Stars
- 11
- Forks
- 0
- Avg merge
- 2h 55m
- Merged PRs (30d)
- 294
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hyparam/hypaware
-
neutral:fix
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
report_commands.js runtime output still says 'server' in four places; one names the destinationOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
Maintainers usually reply within 1 day
All issues in hyparam/hypaware
Similar issues
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
microsoft/playwright#43875 · 1 comment ·
Maintainers usually reply within 1 day
-
Run the dependency drift checkPossibly taken @spaceninja claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 82/100
cloudfour/stylelint-config-cloudfour#683 ·
Maintainers usually reply within 1 day
-
Documentation Enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
JSPrismarine/JSPrismarine#2706 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PostHog/posthog-js#5524 ·
Maintainers usually reply within 2 days
-
enhancement good first issue help wanted
Difficulty 2/5 Half a day Newbie friendliness 66/100
AlphaaCode/Popbook#10 ·