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
Introduce APIError for Sync Calls from CLI to Orchestrator Node #4366
Introduce APIError for Sync Calls from CLI to Orchestrator Node #4366
Changes from 5 commits
b7edf08
c4e9ac8
62f9a2d
0f0fe07
7a22883
f5dc730
af77b2f
3548a73
3336679
4de9f18
6b8d0b3
c7a7dde
2df4031
7ec8f2c
65ffc35
af6557a
3f32999
c560b85
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
it doesn't sound right that internal and backend components depend on
apimodels
which are meant for the http API between frontend (api server) and clients.Some suggestions:
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.
Done, please let me know your thoughts about it.
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.
We should also return:
Keep in mind that some of this information are already in the http headers, such as status code and request id. It might be redundant to serialize them in the APIError. Maybe we should omit serializing them, and just have the client set those values from the headers.
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.
I have added the RequestID. However, adding a bacalhau specific error code is tricky at this point. Mainly because we are need to make sure that we properly propagate error codes correctly every where. In addition, we need to think about how to formulate error codes for errors that occur before even we reach to bacalhau specific components, for example echo server middlewares.
I think we should pick that up in follow ups. Let me know what you think
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.
Yeah please feel free to do this in a follow up PR. What I had in mind is something similar to the code below. The idea is to have standard error codes that can be used by our core components and even the modules if the errors apply, while still enabling the modules to define their own specific error code, such as
BucketNotFound
andContainerStartFailed
The
HTTPCode
can be explicitly provided, inferred from the error code if it is a standard one, or fallback to 500.What I really liked in your PR is the introduction of
Component
field which helps identify the source of the error and also removes the need for these error codes to be globally unique. I would just make the components more readable and descriptive, such asS3Publisher
,Docker
instead of abbreviations. To simplify things, I am proposing the default component to beBacalhau
, which doesn't mean much, but will allow us to incrementally improve the coverage of better errors.Also as we progress, we should allow components to override the
Component
piece of the errors. Meaning a job not found error withJobStore
component doesn't help much compared to knowing the component that actually called the job store. We don't need to do these changes today, but just thinking ahead.What do you think?