Sweep rebuilds the partition path with path.join where the cleanup id was hashed from path.resolve
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 65/100
- Issue type
- Refactor
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, node.js
- Domain
- backend
Research direction
Read src/core/cache/purge-cleanup.js, comparing relativePartition near line 20 with the sweep near line 182. Add a test using a non-normalized cacheRoot spelling; done when the sweep derives partitionDir with the same normalization as cacheCleanupId and the test passes.
Written by the indexing model from the issue text.
Description
Source: #2027 at 24be140b6ba1c9371564af4a1645bf85550e29ec
Location: src/core/cache/purge-cleanup.js:182 vs :20
Severity: nit
Evidence
relativePartition hashes ids from path.resolve on both cacheRoot and partitionDir; the sweep rebuilds with path.join(cacheRoot, job.partition). Confirmed at head 24be140b. Triage re-derived the failure envelope: a divergent cacheRoot spelling still reaches the same lock-directory inode and the same lstat target through the filesystem, and a claim failure throws busy() inside the try at :183, caught at :194 and retried next tick. The widened catch means a persistently failing entry retries silently, but the worst case is one leaked journal file, exactly the pre-fix steady state, never a wrong unlink.
Why deferral is safe
Fails safe in every direction that was probed; aligning the normalization is a consistency cleanup, not a correctness need.
Acceptance condition
The sweep derives partitionDir with the same normalization cacheCleanupId uses, with a test exercising a non-normalized cacheRoot spelling.
Review preference; backlog only. A human may explicitly delegate it with neutral:fix.
- Dominant language
- JavaScript
- Stars
- 11
- Forks
- 0
- Avg merge
- 2h 49m
- Merged PRs (30d)
- 302
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
-
docs: ollama.md says --source ollama adds to an existing install, but without --force it refusesOpen
Difficulty 2/5 Under an hour Newbie friendliness 62/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
-
502 on Node 26: ERR_INVALID_ARG_VALUE: Setting the TLS ServerName to an IP address is not permittedOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
github/paste-markdown#129 · 2 reactions ·
-
bug
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
obsidianmd/obsidian-help#1164 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
richardcase/skills#26 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day