Skip to content

fix(installer): name a Launchpad API timeout as an outage - #7163

Merged
kovtcharov-amd merged 1 commit into
amd:mainfrom
ityashag:fix/launchpad-api-unreachable
Nov 11, 2026
Merged

kovtcharov-amd merged 1 commit into
amd:mainfrom
ityashag:fix/launchpad-api-unreachable

Conversation

@ityashag

Copy link
Copy Markdown
Contributor

When Launchpad's API stops answering, the Linux CLI check now says so. It used to say the PPA step failed "for a reason other than a Launchpad outage", which sent authors looking for a bug in their own PR: on 2026-11-11, main and several PRs failed this way for hours. A timeout is blamed on Launchpad only when apt reached other repositories, so an offline machine isn't misread as an outage.

Closes #7162

Test plan

  • pytest tests/unit/test_init_command.py -k Launchpad: 7 passed. The two new outage tests fail on main; the two "not Launchpad" tests (offline machine, timeout outside launchpadlib) pass on both.
  • On the real logs from the failing runs (main, PR), the check now returns "add-apt-repository could not reach Launchpad to look up ppa:lemonade-team/stable (TimeoutError: [Errno 110] Connection timed out)…" instead of nothing.
  • pytest tests/unit/test_init_command.py: 206 passed.
  • python util/lint.py --all: passed.

When add-apt-repository times out reaching Launchpad, the Linux CLI check
said it failed "for a reason other than a Launchpad outage", so an upstream
outage read as a bug in the change under test.

The outage check now recognizes a timeout or dropped connection inside
launchpadlib, as long as apt reached some other repository, so an offline
machine still isn't blamed on Launchpad.

Refs amd#7162
@github-actions

Copy link
Copy Markdown
Contributor

Verdict: Approve

Sometimes add-apt-repository can't reach Launchpad's API to look up the Lemonade PPA, and it times out. The Linux CLI job now names that as a Launchpad outage instead of a generic failure. The new check is deliberately narrow. It only blames Launchpad when the traceback came from Launchpad's own client library and apt reached some other repository in the same run. A machine that is itself offline therefore still gets the raw error. I found no blocking issues.

I couldn't run gh pr view in this job because the sandbox failed to start, so this review rests on the diff alone, not the PR description.

Real-world evidence

N/A: no evidence bundle was produced. The change only affects how the Linux CI job reads the logs from a failed PPA install. gaia init doesn't call this function today. This verdict rests on static review and the four new unit tests.

🔍 Technical details

Issues found

🟢 DNS and TLS failures to the Launchpad API still fall through (src/gaia/installer/lemonade_installer.py:135). The pattern matches only TimeoutError, ConnectionResetError and RemoteDisconnected. A DNS failure for api.launchpad.net alone raises something like httplib2.error.ServerNotFoundError or socket.gaierror, and that still exits through the "reason other than a Launchpad outage" branch. This is safe because it fails loudly with the raw log. Add those names only if CI actually hits them.

Checks run

  • Sibling paths: the only caller is .github/workflows/test_gaia_cli_linux.yml:100, which joins add-apt.log and apt-update.log before diagnosing. The online and offline signals therefore both reach the function, as the tests assume. Nothing in src/ calls it, so gaia init behaviour is unchanged.
  • Ordering: the new branch sits after the GPG-key check and before the index-fetch check, so the existing diagnoses and their tests keep their precedence.
  • Online signal: (?!\S*launchpad) correctly ignores ppa.launchpadcontent.net hits, and Get:1 file:/… lines don't count because the pattern requires https?://. The offline test covers exactly that mirrorlist case.
  • Known bug classes: this adds no waits, subprocesses or shared state. It improves honest status: an outage is now distinguished from a local network failure.
  • Docs drift: there is no user-facing doc for this message, so nothing is stale.

Strengths

  • The fixtures are trimmed from a real CI log, and the negative tests cover the two ways this could blame Launchpad wrongly: the machine is offline, or the timeout came from outside launchpadlib.
  • Reporting the last error in a chained traceback (api_errors[-1]) names the final cause instead of an intermediate one, and a test covers it.

@ityashag

Copy link
Copy Markdown
Contributor Author

@kovtcharov-amd this is ready for your review, and the bot approved it. The four red checks are a runner network failure, not this change: each stops in apt with Temporary failure resolving 'azure.archive.ubuntu.com' before any GAIA code runs, and the unit tests pass on Linux, macOS and Windows. Could you re-run the failed jobs? A fork can't.

🔍 Technical details
  • Setup journey (ubuntu-24.04): fails in Install Chromium (apt exit 100).
  • Test GAIA CLI on Linux: fails in Install system dependencies (apt exit 100), before the Lemonade PPA step, so it doesn't reach the new diagnosis yet.
  • Offline Integration Tests: apt can't resolve azure.archive.ubuntu.com, archive.ubuntu.com or security.ubuntu.com.
  • Unit Tests Result: fails only because Offline Integration did.

On the bot's 🟢 note: I left DNS failures to api.launchpad.net out on purpose. Today's runs only showed timeouts and dropped connections, so I'll add DNS failures if CI ever hits one.

@kovtcharov-amd
kovtcharov-amd added this pull request to the merge queue Nov 11, 2026
Merged via the queue into amd:main with commit ebd2573 Nov 11, 2026
44 of 48 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tests Test changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CI: a Launchpad API timeout is reported as "a reason other than a Launchpad outage"

2 participants