Worker RX buffer clearing
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 28/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- go
- Domain
- distributed-systems, networking
Research direction
No files or tests are named. Start by tracing worker RX-channel handling through state 1, state 5, the proxyloop, and path-assertion IPC messages; determine whether stale messages can survive state changes and fill the channel. Done requires an agreed buffer-clearing policy and tests demonstrating that stale messages cannot reach a newly claimed worker or cause a full-buffer panic.
Written by the indexing model from the issue text.
Description
In theory, a router may attempt to send messages to a worker which has entered a different state and is no longer listening to their RX channel. When that happens, the router will begin filling their RX channel buffer, and we'll panic when their RX channel buffer is full.
Do we perhaps want workers to clear their RX channel buffer when entering or exiting certain states? In addition to just being a good hygiene practice, this might be a simple way to provide "endpoint safety" -- that is, to prevent the following degenerate scenario:
Bob is a censored user currently proxying his traffic through the worker in slot 3 of Alice's worker table. In the middle of an HTTP request, Bob abruptly disconnects. There are several chunks of bytes destined for Bob's client which are still in transit. Charlie quickly claims slot 3 in Alice's worker table. The chunks of bytes destined for Bob now arrive at Alice's downstream router, which routes them to Charlie.
Another scenario we need to consider: Is it currently possible for a path assertion IPC message to sit and grow stale in a worker's RX buffer? If so, my hunch is that producer workers should clear their RX buffers twice: once before listening for a non-nil path assertion in state 1, and once before kicking off the proxyloop in state 5.
- Dominant language
- Go
- Stars
- 57
- Forks
- 1
- Avg merge
- 20h 26m
- Merged PRs (30d)
- 13
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from getlantern/unbounded
-
bug
getlantern/unbounded#212 · 1 assignee ·
-
team_apps
getlantern/unbounded#204 · 2 comments · 1 assignee ·
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
getlantern/unbounded#200 · 8 comments ·
-
BU 1.0 Open
Difficulty 5/5 Over a week Newbie friendliness 15/100
getlantern/unbounded#199 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
getlantern/unbounded#198 ·
All issues in getlantern/unbounded
Similar issues
-
optimization optimization:agents-md-curator
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
githubnext/gh-aw-cao#13143 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
blinklabs-io/bursa#904 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
yanet-platform/ipfw-go#129 ·
-
bug confmap/provider/googlesecretmanagerprovider needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
open-telemetry/opentelemetry-collector-contrib#51273 · 2 comments ·
-
bug: AI Gateway client filter lists "Unknown" twice when NULL and literal Unknown clients coexist Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100