Relay shows Baton Connected after the plugin has gone, and never accepts it again
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- networking
Research direction
Start with the receive loop in relay/src/state.rs around line 745 and read the Windows behavior described in #254. Decide how the relay can detect a disconnected plugin when Ok(0) is ambiguous, considering the heartbeat or blocking-reader options in the issue. Done means the relay shows :( No Baton Connection after disconnection and accepts a reconnect without manual IPC controls.
Written by the indexing model from the issue text.
Description
Describe the bug
Once the relay has accepted the plugin, it never notices the plugin going away. The window keeps showing :) Baton Connected!, and a plugin that reconnects is never served, so the only recovery is Disconnect IPC then Connect IPC, or restarting the relay.
The receive loop in ipc_connect treats Ok(0) as "no data yet" and keeps polling (relay/src/state.rs:745). On Windows, interprocess returns Ok(0) both for an empty pipe and for one whose other end has closed (see #254), so the loop cannot tell the two apart and never exits. The BrokenPipe arm below it is unreachable on Windows for the same reason. accept() is only called again after that loop exits, so nothing new is accepted.
In the lab this followed directly from #254: the plugin dropped the connection after its failed handshake, but the relay still showed Baton Connected, which made the problem look like it was further down the line.
To Reproduce
- On Windows, start the relay, then X-Plane, so the plugin connects.
- Untick PilotDataSync in Plugin Admin, or quit X-Plane.
- The relay still shows
:) Baton Connected!. - Re-tick the plugin. Nothing reaches the relay until
Disconnect IPC/Connect IPCis pressed.
Expected behavior
The relay notices the plugin has gone, shows :( No Baton Connection, and goes back to accepting, so the plugin can reconnect without anyone touching the relay.
Additional context
Because a read cannot distinguish "empty" from "closed" on Windows, this needs a signal other than the read result. Options include a heartbeat line from baton with a timeout on the relay side, or a blocking reader thread, where Ok(0) really does mean closed. baton already writes SHUTDOWN on a clean stop, but that does not cover X-Plane crashing or the handshake failing.
- Dominant language
- Python
- Stars
- 4
- Forks
- 9
- Avg merge
- 4d 17h
- Merged PRs (30d)
- 7
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
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 oss-slu/PilotDataSynchronization
-
area:docs area:xplane-plugin documentation needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
oss-slu/PilotDataSynchronization#259 ·
Maintainers usually reply within 3 days
-
Connect TCP with an invalid address is silent in the event logPossibly taken @PRINCEKK122 claimed this 22 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
oss-slu/PilotDataSynchronization#241 ·
Maintainers usually reply within 3 days
-
cluster_pilots.py shows a traceback for a bad --k and leaves outputs when --truth is invalidPossibly taken A pull request linked to this issue is open or already merged. Openarea:ml bug python
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
oss-slu/PilotDataSynchronization#232 ·
Maintainers usually reply within 3 days
-
Document running the Python listener on a second PCPossibly taken @Omanhene20 claimed this 3 days ago. Openarea:docs area:ml area:relay documentation needs-triage
Difficulty 3/5 1-2 days Newbie friendliness 70/100
oss-slu/PilotDataSynchronization#264 · 1 assignee ·
Maintainers usually reply within 3 days
-
data_logger stops with a traceback if its CSV is open in ExcelPossibly taken @jmacd867 claimed this 10 days ago. Openarea:ml bug needs-triage python
oss-slu/PilotDataSynchronization#263 · 1 assignee ·
Maintainers usually reply within 3 days
All issues in oss-slu/PilotDataSynchronization
Similar issues
-
`destroy` sans terminal répond « Aborted. » au lieu de réclamer `--yes` comme `clean` et `reset`Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
stephrobert/dsoxlab#354 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
jasonacox/pypowerwall#472 ·
Maintainers usually reply within 1 day
-
[Bug]: DoubleMLRDDData accepts a score_col that is no data column (as in its docstring example); the running variable then becomes a covariate and RDFlex failsPossibly taken @vrjdev claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
DoubleML/doubleml-for-py#455 ·
Maintainers usually reply within 1 day
-
[Bug]: Python mod.Box[T] annotation gets a false generic_arg edge that replaces the parameter_type one ('is' on tree-sitter nodes)Possibly taken @rohit-jsfreaky claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Graphify-Labs/graphify#5110 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
assafelovic/gpt-researcher#2277 ·
Maintainers usually reply within 10 days