[VPEX][5c] Skip constraint cache writes under --check#5854
Conversation
Integration test reportCommit: ad1b317
8 interesting tests: 4 SKIP, 2 KNOWN, 1 RECOVERED, 1 flaky
Top 10 slowest tests (at least 2 minutes):
|
af9d41b to
c2e8b69
Compare
8b12b87 to
4716210
Compare
anton-107
left a comment
There was a problem hiding this comment.
Approving. Tight, correct follow-up: writeCache threaded through FetchConstraints with the pipeline passing !p.Check, and an existing cache is still read for offline fallback (reading isn't a mutation) — exactly right. Test pair is the right shape: unit (TestFetchConstraintsSkipsCacheWriteWhenDisabled) plus the strengthened end-to-end TestPipelineCheckMutatesNothing asserting the cache dir stays empty. All call sites updated. No findings.
4716210 to
d6462fd
Compare
d6462fd to
3127207
Compare
4bd0477 to
b09b9ce
Compare
|
codex review [P2] — duplicate databricks-connect pins — fixed in b09b9ce. Confirmed the bug (reproduced: 2 pins for both Fix: the multi-line branch now scans the whole array span ( |
A --check dry run must not mutate disk, but FetchConstraints wrote the fetched artifact into the cache dir on every successful live fetch — so a dry run still populated the cache whenever it was writable, even though the pipeline skips every other write-side step under --check. Thread a writeCache flag through FetchConstraints; the pipeline passes !p.Check. An existing cache is still read for offline fallback, since reading is not a mutation. Assert both directly (FetchConstraints with writeCache=false leaves the cache dir empty) and end-to-end (the --check pipeline test now checks the cache dir stays empty too). Reported by codex review of the pipeline PR. Co-authored-by: Isaac
Address two correctness nits from review of the pipeline PR (#5851). Since that PR was already queued to merge, the fixes land here in the follow-up. - mergeDatabricksConnect only ever *replaced* an existing databricks-connect element, so a default-mode sync of an existing project that didn't already pin databricks-connect wrote the file back with no pin; uv installed nothing and validate failed with E_VALIDATE. It now *inserts* the pin — into the dev array (single- or multi-line), creating the dev key and the [dependency-groups] table when absent — mirroring RenderFreshPyproject. Constraints-only (empty value) stays a no-op; the insert path is idempotent. - Greenfield rendered name = filepath.Base(ProjectDir), which is "." when run from the project's own directory (and "/" at root) — not a valid PEP 621 name, so uv sync rejected the file. projectName() now resolves via filepath.Abs and sanitizes to a valid PEP 508 identifier, falling back to a default when nothing usable remains. Co-authored-by: Isaac
b09b9ce to
ad1b317
Compare
Why
Codex review of the pipeline PR (#5851) flagged that a
--checkdry run still writes to disk:FetchConstraintspopulates the on-disk constraint cache on every successful live fetch, so--checkmutated the cache directory whenever it was writable — even though the pipeline deliberately skips every other write-side step (writability probe, package-manager availability, the pyproject.toml write) under--check.The cache lives under
os.UserCacheDir()and is disposable, so this was never a correctness or safety bug. But the code frames--checkas performing no writes, and this was the one path that broke that framing. This makes behavior match the contract.What
writeCache boolthroughFetchConstraints. Whenfalse, the successful live-fetch path skipswriteCacheAtomic. An existing cache is still read for offline fallback, since reading is not a mutation.!p.Check, so a real run caches as before and a dry run does not.Testing strategy
TestFetchConstraintsSkipsCacheWriteWhenDisabled— a live fetch withwriteCache=falsesucceeds but leaves the cache dir empty.TestPipelineCheckMutatesNothing— strengthened to assert the cache dir stays empty after a--checkrun (previously it only checked the project file).go build,go test,golangci-lint(0 issues),deadcode,gofmt— all green.About this stack
Follow-up to the
databricks local-env python syncstack. It is stacked on #5851 (the six-phase pipeline) because the fix spans two layers: the cache write lives in the fetch layer, but the--checkdry-run concept it must respect only exists in the pipeline. Review bottom-up — this PR's diff shows only the cache-write change.This pull request and its description were written by Isaac.