Streaming jobs can bypass timeouts when output has no newline
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 65/100
Direzione di ricerca
The issue is in packages/syft-job/src/syft_job/job_runner.py in the _execute_job_streaming() function. Start by understanding the selector loop and the readline() call. Look at how timeouts are currently checked. The fix likely involves reading available bytes without blocking, perhaps using os.read or checking fileobj.read(1) in a non-blocking mode. Write a test that reproduces the bug using a script that outputs without a newline and sleeps. Verify the timeout is enforced after your changes.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
The streaming job runner can block while reading output that does not end with a newline, preventing the configured timeout from being enforced.
In packages/syft-job/src/syft_job/job_runner.py, _execute_job_streaming() waits for readable output using a selector and then calls:
line = key.fileobj.readline()
A pipe becoming readable only guarantees that some data is available. It does not guarantee that a complete line is available. If a job writes partial output without a newline and then continues running, readline() can block until the process writes a newline or exits.
While blocked inside readline(), the loop cannot execute its timeout check. If the process exits before readline() returns, the job may finish without being marked as timed out even though it exceeded the configured timeout.
How to Reproduce
-
Create a job whose
run.shwrites output without a trailing newline and then sleeps:#!/bin/bash printf "working" sleep 10 -
Run the job using streaming output with a timeout shorter than the sleep duration, for example:
timeout=1 -
Observe that the selector detects the available
workingoutput. -
The subsequent
readline()call waits for the process to exit because no newline was written. -
The one-second timeout is not enforced while the runner is blocked.
A minimal Python reproduction of the underlying behavior is:
import selectors
import subprocess
import time
process = subprocess.Popen(
["bash", "-c", "printf working; sleep 5"],
stdout=subprocess.PIPE,
text=True,
)
selector = selectors.DefaultSelector()
selector.register(process.stdout, selectors.EVENT_READ)
start = time.monotonic()
for key, _ in selector.select(timeout=0.1):
output = key.fileobj.readline()
print(output, time.monotonic() - start)
Although output becomes available immediately, readline() returns only after approximately five seconds when the process exits.
Expected Behavior
The streaming runner should enforce the configured timeout regardless of whether job output contains newline characters.
Reading available output should not block the monitoring loop. Possible approaches include non-blocking reads, reading available chunks instead of complete lines, or otherwise ensuring that timeout checks continue while partial output is buffered.
Tests should cover a process that writes partial output without a newline and then runs longer than its configured timeout.
Screenshots
Not applicable. This behavior occurs in the job runner’s process-monitoring logic.
System Information
- OS: Reproduced on a POSIX environment
- OS Version: Not applicable
- Language Version: Python
- Package Manager Version: Not applicable
- Browser: Not applicable
- Browser Version: Not applicable
Additional Context
The non-streaming execution path uses process.communicate(timeout=timeout) and is not affected by this specific blocking readline() behavior.
Duplicate searches for streaming output without newlines, selector/readline timeout behavior, and hanging job timeouts found no matching open or closed issue.
- Lingua principale
- Python
- Stelle
- 10k
- Fork
- 2k
- Merge medio
- 23h 19m
- PR unite (30g)
- 21
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di OpenMined/PySyft
-
Type: Bug :bug:
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Enclave pkg:syft-enclave
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
OpenMined/PySyft#9489 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Type: Testing :test_tube:
Difficoltà 3/5 1-2 giorni Idoneità per principianti 38/100
OpenMined/PySyft#9411 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Bug when using in_memory_cacheForse di nuovo libera @prabindersinghh l’ha presa 229 giorni fa e non c’è nessuna pull request aperta. ApertaType: Bug :bug:
OpenMined/PySyft#9410 · 4 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Syft client log in is slowApertaType: Improvement :chart_with_upwards_trend:
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
OpenMined/PySyft#9409 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di OpenMined/PySyft
Issue simili
-
pydanty:is-working
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
pydantic/pydantic-ai#8843 ·
I maintainer di solito rispondono entro 1 giorno
-
breaking change enhancement server
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
sktime/sktime#11310 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno