Skip to content
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

Improved notification for direct-io logging #2519

Merged
merged 1 commit into from
Jan 28, 2025

Conversation

edmondop
Copy link
Contributor

See #2505

@@ -47,6 +48,13 @@ impl RocksError {
{
Self::DbLocked(err)
} else {
if err_message.contains("Direct I/O is not supported") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be inclined to have a check at the top level (ie else if) and then return a new named error Self::DirectIOUnsupported(err) as we do in the case of it being locked - then the instructions for what to do can be part of the error message. But i defer to @AhmedSoliman for opinions

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds a more robust approach, I guess I wanted to be as little intrusive as possible 🤣

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No question that what @jackkleeman suggested is a nicer approach. I'm okay with either approaches considering that this is quite a niche case. Perhaps we go with what @edmondop proposed and when this list of error expands we can bubble them up.

The reason I don't feel strongly about it is because it wouldn't impact the higher layer in this case.

Copy link
Contributor

@AhmedSoliman AhmedSoliman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest we merge this one

@edmondop
Copy link
Contributor Author

Agreed @AhmedSoliman , after thinking about it, here the point is not so much to have a separate error type to match it upstream and take more precise behavior, but simply provide a more verbose explanation of this error

@AhmedSoliman AhmedSoliman merged commit ad4e5ee into restatedev:main Jan 28, 2025
12 checks passed
@AhmedSoliman
Copy link
Contributor

Thanks @edmondop for making Restate better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants