Skip to content

fix(cli): bound readiness poll requests - #911

Open
Ghraven wants to merge 2 commits into
apache:mainfrom
Ghraven:fix/cli-open-ready-timeout
Open

Ghraven wants to merge 2 commits into
apache:mainfrom
Ghraven:fix/cli-open-ready-timeout

Conversation

@Ghraven

@Ghraven Ghraven commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Summary

  • add a timeout to the CLI readiness poll used before opening the local UI
  • cover open_when_ready() so the readiness request stays bounded

Tests

  • python -m pytest tests/test_cli_open_when_ready.py -q
  • python -m py_compile burr/cli/__main__.py tests/test_cli_open_when_ready.py
  • git diff --check

@CanReader CanReader left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The timeout itself is right, I tested it against a socket that accepts but never answers and the loop now retries instead of hanging. But I think the new test will break CI.

  • tests/test_cli_open_when_ready.py imports burr.cli.__main__, which calls require_plugin and needs loguru. CI installs .[tests,tracking-client,tracking-server,graphviz], and that doesn't include loguru. Locally with the same deps I get ImportError: Missing plugin start! at collection, and since CI runs pytest tests this fails the whole job. A pytest.importorskip("loguru") before the import should be enough, or add the cli extra to the CI install.
  • The 3.9 job has a second problem: _command uses addl_env: dict | None = None and there is no from __future__ import annotations, so importing the module on 3.9 raises a TypeError. This was already there but nothing imported the module in tests before. Optional[dict] fixes it (Optional is already imported). If #913 lands first and drops 3.9 this one goes away.

Small ones:

  • OPEN_WHEN_READY_TIMEOUT_SECONDS is right under the logging setup, so it looks like part of it. Maybe move it next to open_when_ready.
  • The test only covers the happy path. A case where the first requests.get raises ReadTimeout and the retry works would test the actual bug.

@Ghraven

Ghraven commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor Author

Thanks for checking this. I reproduced the collection failure without loguru. 8237743 skips this optional CLI test module when loguru is absent, changes the existing annotation to Optional[dict] for Python 3.9, and places the timeout constant next to the readiness helper.

I also added a ReadTimeout-then-success regression that verifies both requests receive the timeout, one retry sleep occurs, and the browser opens only after success. Both focused tests pass on Python 3.9 with the CLI dependencies installed; without loguru the module skips cleanly. Black, isort, Flake8, license-header and diff checks pass. Full CI is not verified: current head checks show labeling/mergeability success, with triage skipped.

CI follow-up: the workflow-runs API reports Build Burr and Release Validation as action_required on this head, and documentation as startup_failure. No test jobs have run in those workflows. I have not changed the workflows or rerun them; the full CI result remains unverified.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants