Repository navigation
[Bug]: Python API Run.logs() returns nothing for a finished run #4175
Description
Steps to reproduce
from dstack.api import Client
c = Client.from_config()
r = c.runs.get("<a run that has finished>")
print(len(b"".join(r.logs()))) # 0
print(len(b"".join(r.logs(replica_num=0)))) # the actual logsActual behaviour
logs() yields nothing for any terminal run - no exception, no warning. dstack logs <same run> prints the logs in full.
_find_job matches on replica_num alone when it is given, but when it is None it matches only a submission whose status is RUNNING:
dstack/src/dstack/api/_public/runs.py
Lines 420 to 429 in 2517069
Once a run is terminal nothing is RUNNING, so _find_job returns None and logs() returns an empty generator. The CLI is unaffected because its --replica argparse default is 0, so it never passes None.
Expected behaviour
logs() with default arguments should return the logs of a finished run, as the CLI does - fall back to replica 0 when no submission is running, or raise instead of yielding nothing.
dstack version
master at 2517069, server run from source.
Activity
r4victor commentedon Aug 20, 2026
Some history, so the fix doesn't undo the rolling-deploy behaviour.
Both
logs()andattach()defaulted toreplica_num=0with no status check until #2821 (rolling deployment for services) changed them toNoneand added theRUNNINGcondition, documented as "any running replica". That's right forattach: under a rolling deploy replica 0 may be draining or gone, and you can't tunnel into a dead container anyway.It's wrong only for
logs(), which shares_find_jobbut should outlive the replica. So the fallback belongs in the logs path;attachshould keep matching any running replica.