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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(file source): Allow file pattern with curly braces in include directive #5927
fix(file source): Allow file pattern with curly braces in include directive #5927
Changes from 9 commits
8681043
d819e25
ba99672
497c976
9c38ced
168bd1e
ee8f83c
7001445
3954aed
81b936a
47f0dcb
22860d6
243226a
522885d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the design choices for the path provider was that it's never supposed to push it's error to the caller while enumerating the paths.
My thought process was this.
If the paths provider errors out - how would the caller - file server handle it? It is a meaningful error condition to recognize and act upon there? I deemed not, and decided that there's no good purpose to allow errors to be pushed to the file server. If the error is temporary - the valid behaviour would be to just log and return an empty iter. If the error is critial, and we should terminate the file server - then we should pass the error, however that situation just couldn't occur at the time.
There is another way I can think of that file server can react to an error - and that is, upon receiving a certain kind of error - just skip the current update, and keep using the paths obtained from the previous iterations. It may be useful for some kinds of use cases, like when the paths provider suddenly became unavailable, but we would rather use stale data and hope for the path provider to become available again at next call than terminate the file server. That,s however, also wasn't useful at the time.
The situation may have changed, and the change might be justified, but I'd like to validate that this way of handling error is what we're looking for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That for the rationale. Also don't have a clear cut answer to this, but my thoughts were the following:
This information can be encoded in/inferred from the associated
Error
type. In the case of theGlob
PathProvider
andGlobError
, the caller can decide that e.g.InvalidIncludePattern
is unrecoverable because it is a programmer error, whereas aWalkError
can be temporary (due to the directory structure it is executed in), and ignored.I would even argue that the caller has more information available if the error is recoverable or not, rather than deciding it in the
paths
implementation. With this change, the caller can still decide to ignore all errors, but the inverse is not true. If thepaths
implementation decides to unwrap and panic, the caller has little chance to override this behavior.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. The caller can't be coupled with an exact error type to carry this information though - otherwise it won't be generic. To establish a generic protocol we either have to add a trait to the error type, or use a trait-owned wrapper type to encode this data - i.e.
Result<..., PathsError<Self::Error>>
, whereenum PathsError<T> { UsePreviousPaths(T), Fatal(T) }
.Yet another question is how much sense does this protocol extension make. In other words - do we need the caller need to be able to decide to ignore the errors, etc? I mean, currently, we're just doing
?
there. Do we need to further extend this protocol?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you're right. We don't specialize the
PathProvider
yet in theFileServer::run
function.It makes the trait a bit more verbose, but it does exactly solve the problem we are discussing. I'm leaning for it.