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

Handling invalid connections #102

Open
marcbowes opened this issue Mar 25, 2021 · 10 comments
Open

Handling invalid connections #102

marcbowes opened this issue Mar 25, 2021 · 10 comments

Comments

@marcbowes
Copy link

If a user incorrectly specifies their connection setting (e.g. typos the IP address), then bb8's get method will hit errors and retry until the timeout. Is there a way of marking certain errors as "just give up"?

@djc
Copy link
Owner

djc commented Mar 29, 2021

There is currently no such way that I'm aware. The question is if this is really what you want -- it seems likely that many of these kinds of errors could be transient, so retrying them before timing out might actually be desirable.

@marcbowes
Copy link
Author

Yeah, I agree with you in general. In my case, we have a shell utility connecting to a db. If the user typos their db name then it takes 30s (the timeout) to return an error. I know logging with the error sink will help, but really, retrying is pointless.

@djc
Copy link
Owner

djc commented Mar 29, 2021

Maybe you should just set the timeout lower in your application?

@marcbowes
Copy link
Author

Well, that’s not the only problem. The other is that the error message just says timeout.

Do you think bb8 should not have the concept of an exception that should not be retried on (is terminal for the get attempt and is exposed to the user)?

@djc
Copy link
Owner

djc commented Mar 29, 2021

That's a pretty abstract question, to which I don't have a concrete answer. I'm skeptical that there's a straightforward way to implement this that doesn't make things worse for other users and doesn't incur a whole bunch of complexity for what in my opinion is limited benefit.

bb8 is chiefly intended for long-running (server) processes. Optimizing for startup doesn't necessarily make sense. You might just start a connection without bb8 to start with to validate the user's input.

@marcbowes
Copy link
Author

The simplest thing I could think of would be to add

fn should_retry(err: &Self::Error) -> bool

to ManageCollection with a default impl that returns true. That's backwards compatible and doesn't "incur a whole bunch of complexity" in my opinion.

The get API already supports exposing the manager defined Error type:

pub async fn get(&self) -> Result<PooledConnection<'_, M>, RunError<M::Error>> 

I'm probably missing something, though.

@djc
Copy link
Owner

djc commented Mar 30, 2021

That seems fine to me, let's have a PR (please add some tests).

@marcbowes
Copy link
Author

I ran into an issue where ManagedConnection::Error is not Clone. The problem arises because both get and ErrorSink want the error by value, so there needs to be a copy made. Currently, only the sink gets it because get always returns TimedOut and never UserError(M::Error). Not sure how to address this without adding a new bound which would not be backwards compatible.

@marcbowes
Copy link
Author

I opened #104 to discuss the path forward.

@marcbowes
Copy link
Author

In #104 I suggest an alternative where the sink does not get the error in a catastrophe, which seems OK to me.

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

No branches or pull requests

2 participants