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

fix(client): disconnect_reason/read_error is cancel-safe #1347

Merged
merged 3 commits into from Apr 8, 2024

Conversation

niklasad1
Copy link
Member

If/when the connection is closed the cause is fetched by read_error from the background task. It was not cancel-safe which could have side-affects and mutate state such the internal Option could be None and end-up in a panic.

If/when the connection is closed, the cause is fetched by `read_error` from the background task.
It was not cancel-safe, which could have side-effects and mutate the state,
such as the internal Option could be `None` and cause a panic.
@niklasad1 niklasad1 requested a review from a team as a code owner April 8, 2024 12:37
};

Error::RestartNeeded(err)
if let Some(err) = self.disconnect_reason.read().await.as_ref() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Now we're not holding this lock over any await points (at least, I think we aren't?), should we make it a sync RwLock?

Copy link
Member Author

Choose a reason for hiding this comment

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

done nice catch, one dependency removed :)

Copy link
Collaborator

@jsdw jsdw left a comment

Choose a reason for hiding this comment

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

Couple of small comments but looks ok!

Given that the method was actually listed as not being cancel safe, I do think it was prob their fault anyways if that was what led to the issue, but always nice to remove potential footguns :)

@niklasad1
Copy link
Member Author

niklasad1 commented Apr 8, 2024

I do think it was prob their fault anyways if that was what led to the issue, but always nice to remove potential footguns :)

Actually, we have https://docs.rs/jsonrpsee-ws-client/latest/jsonrpsee_ws_client/struct.WsClientBuilder.html#method.request_timeout where the "future/method call" is dropped and it may suffer from this cancel-safety issue and "nothing caused by the user". Thus, an internal jsonrpsee issue as which I forgot about...

But it could be caused disconnect_reason is called in a select loop or that request is dropped by the which is on the user but better to keep everything cancel-safe if possible :)

@niklasad1 niklasad1 merged commit 5c65daf into master Apr 8, 2024
11 checks passed
@niklasad1 niklasad1 deleted the na-client-disconnect-reason-cancel-safe branch April 8, 2024 15:11
niklasad1 added a commit that referenced this pull request Apr 8, 2024
* client: `disconnect_reason/read_error` cancel-safe

If/when the connection is closed, the cause is fetched by `read_error` from the background task.
It was not cancel-safe, which could have side-effects and mutate the state,
such as the internal Option could be `None` and cause a panic.

* fix wasm build

* remove async_lock dependency
@maan2003
Copy link

maan2003 commented Apr 9, 2024

I had a fix in different way, it uses &mut Fut: Future to achieve cancel safety.
See c5ed255

@niklasad1
Copy link
Member Author

I had a fix in different way, it uses &mut Fut: Future to achieve cancel safety.
See c5ed255

Yepp, that works as well but I didn't like the old code and decided to refactor it. The RwLock is basically only "write_locked once" and should be quite efficient anyway because once the connection is closed it should never block (only read locks can be held)

I guess we could change it to a OnceLock instead but I'm quite happy with this for now

elsirion added a commit to elsirion/fedimint that referenced this pull request Apr 16, 2024
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.

None yet

4 participants