Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Windows: peers.py inbox read crashes on os.O_NONBLOCK (bare use; defensive getattr form already used elsewhere) — and the read receipt is persisted before the crash

Ouverte
  • Quelque chose ne va pas ?
#5,511 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

  • #5512 par @Jah-yee — fermée sans fusion

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
38/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
python
Domaine
backend

Piste de recherche

Start with loopx/control_plane/collaboration/peers.py at input_readiness() and compare its os.O_NONBLOCK use with the defensive forms in loopx/collaboration_mcp.py and loopx/control_plane/todos/completion_result.py. Reproduce on Windows with an inbox brief containing inputs; done means the read no longer crashes and the persisted receipt behavior is understood.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

On Windows, peers.py's inbox read path crashes unconditionally whenever a peer request brief carries inputs, because input_readiness() uses os.O_NONBLOCK — an attribute that does not exist on Windows. Two properties make this worse than a plain crash:

  1. It is on the main read path (read_inbox() → input_readiness(), peers.py), triggered by any brief with staged inputs — including the brief shapes in this repo's own test fixtures.
  2. The read receipt is persisted before the crash. After the AttributeError, an after-the-fact look at reads/<request_id>.json shows a recorded read (kind=receiver_cli_read, read_at set) even though the read actually failed — the receipt systematically misreports the outcome.

A one-line fix matches the pattern already used elsewhere in this same codebase (see below).

Repro (Windows, current main)

git rev-parse HEAD          # d74554b48...
python -c "import os; print(hasattr(os, 'O_NONBLOCK'))"   # False on win32

Then call the read path with a brief that has inputs (sandbox registry + workspace, minimal peers.request(...) followed by read_inbox(...)):

File "...\loopx\control_plane\collaboration\peers.py", line 547, in input_readiness
    os.open(path, os.O_RDONLY | os.O_NONBLOCK)
AttributeError: module 'os' has no attribute 'O_NONBLOCK'
  • Crash frame chain: read_inbox → input_readiness (line 547 on current main; 523 on v1.2.2).
  • Before raising, the receipt reads/<request_id>.json is already on disk with kind=receiver_cli_read and read_at written.
  • Briefs without an inputs key do not hit the path (the staging guard returns early) — the failure is deterministic for any input-bearing brief on Windows, and retrying cannot succeed.

The fix already exists in this repo — twice

The defensive form is used elsewhere; only peers.py is bare (both verified on current main, git grep -n "O_NONBLOCK" upstream/main):

  • loopx/collaboration_mcp.py:867 — getattr(os, "O_NONBLOCK", 0)
  • loopx/control_plane/todos/completion_result.py:32 — getattr(os, "O_NONBLOCK", 0)
  • vs. loopx/control_plane/collaboration/peers.py:547 — bare os.O_NONBLOCK

Suggested fix for peers.py (one line, consistent with those two precedents):

os.open(path, os.O_RDONLY | getattr(os, "O_NONBLOCK", 0))

On POSIX this is behavior-identical; on Windows the readiness probe degrades to a blocking open (or can be skipped, matching whatever the other call sites intend).

Impact notes

  • Platform: Windows (any brief with inputs); POSIX unaffected.
  • The persisted-but-failed receipt is the nastier half: any later audit of reads/ concludes the read succeeded. If there is a preferred outcome (e.g. record the read only after readiness succeeds, or record a failure kind), that would fix the misreport too — we're flagging it rather than prescribing, since the receipt-ordering may be intentional for crash recovery.

Our context

We hit this while operating a research squad on Windows against dsh 0.2.0rc2: three parallel workers all died on read_inbox with empty stdout/stderr, and the leftover receipts initially made it look like the reads had succeeded. Happy to turn the fix into a PR if the approach above is agreed — or an alternative if maintainers prefer dropping the readiness probe on Windows.

Langage dominant
Python
Étoiles
6.2k
Forks
596
Merge moyen
7 h 47 min
PR mergées (30 j)
904

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de loopx-project/loopx

Toutes les issues de loopx-project/loopx

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.