Skipped-partition stderr wording omits that non-session skipped rows stay sink-exportable
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript
- Domain
- cli
Research direction
Read src/core/commands/purge.js:128-134 and the related session-target handling at lines 95-96; check the existing purge tests or documentation for how stderr wording is verified. Done means the stderr message or purge documentation explains that skipped rows for non-session targets remain exportable until a successful rerun, with a test or doc check pinning that wording.
Written by the indexing model from the issue text.
Description
Source: #2043 at 94bd66662c08b4ce2fb352978bc93ac45c412532
Location: src/core/commands/purge.js:128-134
Severity: minor
Evidence
The durable purge fence is written only for session targets (src/core/commands/purge.js:95-96, createSessionPurgeStore), so for subtree/ignored/all targets a skipped partition's surviving rows remain query-visible and exportable to configured sinks until a rerun succeeds. The stderr line says only 'may still hold matching rows', which is true but understates the export consequence for those targets.
Why deferral is safe
The message truthfully states non-deletion and the run exits 1, so a user is told the rows survive and chained flows (the privacy skill invokes hyp purge with && chaining) stop before a sync; the export exposure is a consequence of surviving rows, not a claim the message contradicts. Behavior is strictly better than pre-PR, where the wholesale abort left every partition's rows equally exportable with the same wording absent.
Acceptance condition
The stderr line (or the purge documentation) states that for non-session targets skipped partitions' rows remain exportable until a rerun succeeds, with a test or doc check pinning the wording.
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
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bigcalendar/react-big-calendar#2823 ·
-
feature t-tooling
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
documentation enhancement
Difficulty 1/5 Under an hour Newbie friendliness 85/100
OWASP/cve-lite-cli#1480 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
wazuh/wazuh-documentation#10611 ·
Maintainers usually reply within 1 day