Skip to content

fix(patterns): patterns loader temp dir leak - #2192

Open
scottidler wants to merge 1 commit into
danielmiessler:mainfrom
scottidler:patterns-loader-temp-dir-leak
Open

fix(patterns): patterns loader temp dir leak#2192
scottidler wants to merge 1 commit into
danielmiessler:mainfrom
scottidler:patterns-loader-temp-dir-leak

Conversation

@scottidler

Copy link
Copy Markdown

What this Pull Request (PR) does

Stops PatternsLoader from leaking one empty temp directory per fabric invocation.

configure() called os.MkdirTemp directly. It is wired as the plugin's
ConfigureCustom, so it runs on every NewPluginRegistry construction, which means
every fabric invocation created an empty fabric-patterns-* directory that nothing
removed. Details and measurements are in #2190.

Only PopulateDB() and the helpers it calls read tempPatternsFolder, and the
success path already removes the folder in movePatterns. So this moves creation into
ensureTempPatternsFolder(), called from PopulateDB(), plus a deferred cleanup that
also covers the error paths and leaves the loader reusable.

Worth noting for review: a plain defer os.RemoveAll(tempDir) inside configure()
looks like the obvious one-line fix but is wrong. It deletes the folder before
gitCloneAndCopy populates it. Lazy creation is the correct seam.

Verification

  • 20 invocations of fabric -l against a configured ~/.config/fabric/.env:
    20 leaked directories before, 0 after.
  • fabric -U behaves identically before and after: 255 patterns downloaded,
    257 entries installed, loaded marker written, 0 leftover temp directories.
  • go test ./internal/tools/... ./internal/core/... ./internal/plugins/... passes,
    25 packages, exit 0. gofmt and go vet clean.
  • The new tests fail against unpatched code, confirming they cover the regression
    rather than just passing alongside it.
  • Verified on Linux amd64, source build of main at 338b89c.

Related issues

closes #2190

Screenshots

N/A, no user-visible output changes.

`PatternsLoader.configure()` ran `os.MkdirTemp` on every plugin registry
construction, so every fabric invocation left behind an empty
`fabric-patterns-*` directory that nothing ever removed.

Only `PopulateDB()` and the helpers it calls use that folder, and it is
already removed on the success path by `movePatterns`. Move creation into
`ensureTempPatternsFolder()`, called from `PopulateDB()`, and remove the
folder in a deferred cleanup so the error paths are covered too and the
loader stays reusable.

A plain `defer os.RemoveAll(tempDir)` in `configure()` would delete the
folder before `gitCloneAndCopy` populates it, so lazy creation is the
correct seam.

Adds regression coverage: `configure()` must not create the folder, and
`ensureTempPatternsFolder()` must be lazy and idempotent.

closes danielmiessler#2190
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: PatternsLoader leaks one empty temp directory per fabric invocation

1 participant