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

Transport cleaning #215

Merged
merged 11 commits into from
Jul 6, 2021
Merged

Transport cleaning #215

merged 11 commits into from
Jul 6, 2021

Conversation

goodboy
Copy link
Owner

@goodboy goodboy commented Jul 2, 2021

Pulls out some transport related finessing into a new small patchset for other PRs (like #209) to build on.

Mostly trying to get these lower level changes in and see it work in CI.

This change some super old (and bad) code from the project's very early
days. For some redic reason i must have thought masking `trio`'s
internal stream / transport errors and a TCP EOF as `StopAsyncIteration`
somehow a good idea. The reality is you probably
want to know the difference between an unexpected transport error
and a simple EOF lol. This begins to resolve that by adding our own
special `TransportClosed` error to signal the "graceful" termination of
a channel's underlying transport. Oh, and this builds on the `msgspec`
integration which helped shed light on the core issues here B)
@goodboy goodboy requested a review from guilledk July 2, 2021 15:42
Since we currently have no real "discovery protocol" between process
trees, the current naive approach is to check via a connect and drop to
see if a TCP server is bound to a particular address during root actor
startup. This was a historical decision and had no real grounding beyond
taking a simple approach to get something working when the project
was first started.

This  is obviously problematic from an error handling perspective since
we need to be able to avoid such quick connect-and-drops from cancelling
an "arbiter"'s (registry actor's) channel-msg loop machinery (which
would propagate and cancel the actor).

For now we map this particular TCP error, which gets remapped by `trio`
as a `trio.BrokenResourceError` to our own internal `TransportClosed`
which is swallowed by channel message loop processing and indicates
a graceful teardown of the far end actor.
@goodboy
Copy link
Owner Author

goodboy commented Jul 4, 2021

Omg finally 😂

@goodboy
Copy link
Owner Author

goodboy commented Jul 6, 2021

Gonna rerun the suite a few more times.

Pretty sure it's just debugger tests again (which have a bunch of non-determinism) until #220 lands.

@goodboy goodboy merged commit 4d530de into master Jul 6, 2021
@goodboy goodboy deleted the transport_cleaning branch July 6, 2021 12:20
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.

2 participants