"path (...) is not valid" is a highly non-descriptive error and doesn't say anything about what is corrupted if anything #270
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#270
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Action items: audit where we throw a "is not valid" error in the Lix codebase, figure out the conditions they represent and give them at least unique messages, because there are also multiple of them.
there's 10 usages and the bug I was having falls under "Store::isValidPath says its invalid", presumably lix thinks it's gonna copy the path but doesn't but expects to read it afterwards anyway.
suboptimal matrix ref (private beta)
I'm taking at look at this FYI, seeing if I can knock some easy ones off.
This is my identification list so far,
(will be edited), I can't find others. See https://gerrit.lix.systems/c/lix/+/1161LocalFSStore::narFromPath
, testable vianix path-info nixpkgs#bash
(well, until #323 is (maybe)? fixed)queryPathInfo
(see: https://gerrit.lix.systems/c/lix/+/1159)LocalStore::queryPathInfoInternal
(bad hash error, says "invalid-path")LocalStore::queryValidPathId()
.RemoteFSAccessor::fetch
LocalStoreAccessor::toRealPath
BinaryCacheStore::addToStoreCommon
builtins.exec
Other notes:
"is not valid"
when communicating with a remote store....LegacySSHStore::narFromPath
does not appear to have error handling? same with RemoteFSStorehmmmmmmmmmm. it does look like this is for compat with possibly ancient daemon versions, and i don't think we should seriously care about daemons older than 2.3. do we have a history of what the protocol version is?
Alright I have retrieved an answer: any version strictly less than 21, we do not care the slightest bit about, and we can and should just delete the code for it and fail at the very start of the connection.
https://github.com/NixOS/nix/blob/2.3/src/libstore/worker-protocol.hh#L9
Raised an issue to do that: #325
Whilst wrapping my head around the codebase, I was trying to understand precise meaning of e.g. the "InvalidPath" error, and "QueryValidPath" / "isValidPath".
From a user-level error message POV, I've been leaning towards "path blah does not exist in the store", because that's relatively unambiguous.
But within the code (and previously exposed), was the conception of "InvalidPath". As far as I can tell (with some exceptions (maybe many? I can't see others, see cl/1159) this means "the path does not exist in the store".
In contrast, the BadStorePath error means "this store path is not allowed"; sometimes this is just Error.
Personally, invalid is closer to illegal than non-existent, which makes this more confusing than necessary. (Same as "validStorePath" when querying (possibly-remote) stores; though admittedly it they will return false if it's an illegal store path, but that also just means it's not in the store).
i.e. all illegal store paths are a subset of all non-existent store paths.
Admittedly, this is probably leaning into the "very hard breaking API change", but having (and defninig somewhere!) terms for "path is in the store" (curr: validPath), "path is not in the store" (curr: invalidPath), and "path is not allowed to be in the store" (curr(roughly): badstorepath) in a consistent manner would be nice.
(queryValidPath isn't probably the least bad, it's somewhat intuitive especially if functions had doc comments. just queryPath would probably make more sense, though).
I can think of maybe, IllegalStorePath (I mean, BadStorePath is /fine/), and maybe NonResidentStorePath? (that's kinda long though). Missing? Unavailable? PathNotFound?
This issue was mentioned on Gerrit on the following CLs: