Repository navigation
fix(testing): load the isolated postgres fixture from an owned temporary file - #1212
Merged
Merged
Conversation
…ary file The isolated postgres fixture was bundled and then imported from a data:text/javascript;base64 URL. The coverage reporter of the pinned Bun 1.4.3 cannot report a module loaded that way: it aborts the whole coverage run with "panic: range end index 1884 out of range for slice of length 1024" before it prints a summary, so every coverage run that included packages/testing/src/postgres.test.mjs died at the reporting step. The bundle is now written to a temporary file the test owns and imported from there. The bytes are the ones the build produced, the fixture behaves the same, and the directory is removed when the run ends and when the fixture cannot be loaded at all. The file lives in a dist/ directory because it is generated output, which the repository's coverage configuration already ignores, so the coverage report keeps exactly the rows it had. Three regressions cover the new path: the fixture loads from the temporary file with the bundle's own bytes, the owned directory is removed, and a fixture that cannot be loaded leaves nothing behind either.
0xPlayerOne
changed the title
…er its allocation The fixture directory is allocated, then filled, then written and then imported, and each of those steps can fail. Only the import was guarded: a directory that was allocated and then not filled, or a file that could not be written, stayed behind in the temporary directory, and the removal was registered only after a successful load. The allocation and the directory creation are now one guarded step, the write is guarded as well as the import, and the removal is registered before the fixture is loaded. The failure that caused the cleanup is kept as it is; a cleanup that fails too is reported beside it rather than in place of it, so the original error is never lost. Four regressions cover the paths: a directory that cannot be created, a file that cannot be written and a fixture that cannot be imported each leave no directory behind, a cleanup that fails is reported next to the failure that caused it, and a directory the test does not own is left untouched. The bundle bytes and the coverage thresholds are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Coverage fixture cleanup on every post-allocation failure
Current head:
75c2f498d953cc5e9457c7534174c641e7159f7a(tree5bb0ea3a787cecdb18747a593c76fb7b104a0bae), based on the existing PR head085930170ed6c9ea9d88162d3b6ad5f663efb630.This repair keeps cleanup active for every failure after a fixture directory is allocated, including directory setup, fixture writes, and module loading. Cleanup errors are retained alongside the original failure. Tests use owned temporary fixture directories only; no shared-resource cleanup is performed.
Checks
Draft update for review. Auto-merge remains off; no readiness, merge, deployment, or issue-closure claim is made.