Repository navigation
fix(share): refuse an unreadable .hyperframesignore when a snapshot picks files to send - #7573
Conversation
…icks files to send
0.9.35 made snapshotProject and snapshotFiles fall back to scratch-only
exclusions when .hyperframesignore can't be read. That is right for change
detection, but a host that builds an archive from the same snapshot then
includes files the ignore file meant to exclude, including ones named on its
valid lines.
The snapshot is strict again by default and throws invalid_source_ignore.
Change detection opts in with { lenientIgnore: true }, and projectFingerprint,
which names no files, always reads leniently.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
jrusso1020
left a comment
jrusso1020
left a comment
There was a problem hiding this comment.
Reviewed at 5c0edb5c590c3077b2102d1f77b3645806d35a81.
The fix closes the ignored-file export regression. snapshotProject and snapshotFiles now use readSourceIgnore on the default path before returning any file inventory. A mixed valid/unsupported ignore file therefore refuses the export instead of discarding its valid exclusions. Source capture independently retains the same strict reader.
The permissive path is explicit (lenientIgnore: true), and projectFingerprint sets it after the caller options so hash-only change detection remains available. The docs describe the changed default and host opt-in. Generated declarations preserve the existing calls and add the optional argument correctly. I found no production file-selection caller in this repository that opts into lenient behavior.
Validation: isolated share-package build/type checking and all 134 tests passed locally on Node 24.22.2, through pytest-gate.sh. The new mixed-ignore regression fails with main’s snapshot implementation (Missing expected rejection) and passes after restoring this head. Lint and format checks pass. Trial merge with main 6cc734fd is clean. A fresh adversarial source pass found no additional defect.
Scope: audited both snapshot paths, strict/lenient reader behavior, fingerprint consumers, source capture, generated API types and the regression. This is package/local evidence; I did not rebuild the entire repository or run a fresh Desktop/backend walk. Hosts upgrading from 0.9.35 that need permissive handling of unsupported ignore syntax must opt their change-detection-only snapshot calls into lenient handling, as the PR states; export selectors should retain the strict default.
Need: yes, restore the export exclusion boundary · Size: focused API/default fix · Reuse: existing strict and change-detection readers · Simpler: strict default with explicit opt-in · Structure: fine (checked snapshotProject, snapshotFiles, projectFingerprint and source capture; one shared reader selection covers both selectors).
Risk: medium — shared filesystem/export API; failure now refuses file selection.
Verdict: APPROVE
Reasoning: strict selection is restored across both snapshot APIs while explicitly lenient change detection remains supported and tested.
— Rames / cutroom-review
What
snapshotProjectandsnapshotFilesare strict about.hyperframesignoreagain by default: an ignore file this package can't read makes them throwinvalid_source_ignore. Change detection opts into the lenient reading with{ lenientIgnore: true }.projectFingerprintnames no files, so it always reads leniently.Why
#7568 (shipped in 0.9.35) made both snapshot functions fall back to scratch-only exclusions when the ignore file can't be read. That keeps change detection working, but a host that builds an archive from the same snapshot then includes files the ignore file meant to exclude. That covers files named on the file's valid lines too, because one unsupported line makes the whole file unreadable. For example, an ignore file with
private-notes.txtand/renders/would letprivate-notes.txtinto the archive. Before 0.9.35 the snapshot threw, and the archive was refused.How
snapshotProject(dir, { lenientIgnore })andsnapshotFiles(dir, files, { lenientIgnore })choose between the strict reader (readSourceIgnore, the default) and the change-detection reader (readChangeIgnore).projectFingerprintpasseslenientIgnore: true, so export freshness and share status keep working with a gitignore-style ignore file, as they do in 0.9.35.Hosts that call the snapshot functions for change detection need to pass
{ lenientIgnore: true }to keep 0.9.35's behavior there.Test plan
kernel.test.mjstest with one valid and one unsupported line: the default snapshot andsnapshotFilesreject withinvalid_source_ignore, as does a symlinked ignore file, and the lenient snapshot still runs. It fails on main and passes with this change.lenientIgnoreand still pass.projectFingerprintworks with an unsupported or symlinked ignore file, and a readable ignore file excludes its paths both ways.🤖 Generated with Claude Code