Skip to content

fix(cli): stop reporting "up to date" when the Homebrew update check fails - #1298

Merged
phernandez merged 4 commits into
mainfrom
fix/1297-brew-update-false-uptodate
Aug 23, 2026
Merged

fix(cli): stop reporting "up to date" when the Homebrew update check fails#1298
phernandez merged 4 commits into
mainfrom
fix/1297-brew-update-false-uptodate

Conversation

@groksrc

@groksrc groksrc commented Aug 23, 2026

Copy link
Copy Markdown
Member

Closes #1297

Why

  • brew outdated --quiet used empty stdout for both an up-to-date result and several real failures, so Basic Memory could report a failed check as UP_TO_DATE.
  • The quiet output identified an outdated formula but never supplied its target version, producing Update available (latest: unknown).
  • The Homebrew tap can temporarily lag PyPI during release publication, so a PyPI-inferred update must not trigger an automatic Homebrew upgrade.

What Changed

  • Distinguishes Homebrew's current, outdated, and unanswered outcomes.
  • Falls back to PyPI when Homebrew cannot answer, while preventing an automatic Homebrew upgrade from a PyPI-only positive result.
  • Uses brew outdated --json=v2 to report Homebrew's own current_version for a confirmed outdated formula.
  • Preserves Homebrew's failure reason and manual upgrade guidance.

Implementation Details

  • Homebrew exits 1 for both an outdated formula and a command failure, so the exit code is not sufficient.
  • A populated JSON formula entry is authoritative for an outdated result and includes the target version.
  • An empty JSON formula list with exit 0 is authoritative for an up-to-date result.
  • Non-JSON output, malformed JSON, missing version metadata, subprocess failures, and timeouts remain unanswered and raise HomebrewCheckError for the existing fallback path.
  • Tap-qualified names such as basicmachines-co/basic-memory/basic-memory are matched by their final formula component.

Testing

Automated

  • uv run pytest tests/cli/test_auto_update.py -q: 31 passed.
  • uv run ruff check src/basic_memory/cli/auto_update.py tests/cli/test_auto_update.py: passed.
  • just typecheck: passed.

Manual

  • Confirmed brew outdated --json=v2 ada-url exits 1 with a populated formula entry and current_version.
  • Confirmed brew outdated --json=v2 cmux exits 0 with an empty formula list.
  • Confirmed the untrusted Basic Memory tap exits 1 with a non-JSON error, preserving the unanswered/fallback path.

Risks / Follow-ups

  • Availability inferred from PyPI after a Homebrew failure is reported but never automatically installed, because the tap may not yet carry that release.
  • If both Homebrew and PyPI fail, the update check remains FAILED; it is never reported as up to date.

`_check_homebrew_update_available()` decided outdated-or-not purely from
`brew outdated`'s stdout and discarded the return code. Every failure mode
of that command produces the same shape -- non-zero exit, empty stdout,
reason on stderr -- so a failed check was read as "not outdated" and the
caller reported `UP_TO_DATE`. A hard failure to determine the latest
version was reported to the user as success, silently pinning Homebrew
installs to whatever version they happened to have.

Observed with newer Homebrew's third-party tap trust requirement
("Refusing to load formula ... from untrusted tap"), but a stale tap, a
missing formula, brew off PATH, or a network failure all produce the same
empty-stdout shape.

Model the three real outcomes instead of two: exit 0 with empty stdout is
up to date, the package name on stdout is outdated, and anything else is
unanswered and now raises `HomebrewCheckError`. `run_auto_update()` catches
it and falls back to the PyPI comparison, which can answer the question --
the tap can only lag PyPI, never lead it -- and yields a real
`latest_version`, so Homebrew users no longer see "Update available
(latest: unknown)". `source` is unchanged, so remediation still points at
`brew upgrade basic-memory`. If PyPI is also unreachable the existing
handler reports FAILED rather than a false all-clear.

Closes #1297

Signed-off-by: Drew Cain <groksrc@gmail.com>

@chatgpt-codex-connector chatgpt-codex-connector Bot 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f2f66fb7bc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/basic_memory/cli/auto_update.py
`brew outdated` writes progress output ("==> Downloading Homebrew API
data") to stderr on the successful outdated path, so a non-empty stderr is
not an error signal on its own. The outdated-case test asserted against an
empty stderr, leaving nothing to catch a future "stderr means failure"
reading. Use brew's real stderr instead.

This locks the three real result shapes into the suite: exit 0 with empty
stdout (up to date), exit 1 with the tap-qualified formula name on stdout
(outdated), and exit 1 with empty stdout plus an `Error:` stderr
(unanswered). Exit 1 is shared by the middle and last, so stdout stays the
discriminator and the return code only breaks the tie when stdout is empty.

Signed-off-by: Drew Cain <groksrc@gmail.com>
@groksrc

groksrc commented Aug 23, 2026

Copy link
Copy Markdown
Member Author

Follow-up (e136bad) pinning one more empirically-confirmed detail into the tests.

brew outdated --quiet basic-memory exits 1 in both the outdated case and the failure case, so the return code alone cannot discriminate — and on the successful outdated path brew also writes to stderr:

exit 1 | stdout: "basicmachines-co/basic-memory/basic-memory" | stderr: "==> Downloading Homebrew API data"
exit 1 | stdout: ""                                           | stderr: "Error: Refusing to load formula ... from untrusted tap ..."

So neither "non-zero exit" nor "non-empty stderr" is an error signal on its own. The fix keys on stdout first and only consults the return code to break the tie when stdout is empty; stderr is used solely as message text after the decision is made. Two consequences worth flagging for review:

  • The formula name on stdout is tap-qualified (basicmachines-co/basic-memory/basic-memory), not the bare basic-memory. The substring check in _check_homebrew_update_available() is load-bearing — tightening it to an exact match against PACKAGE_NAME would break the outdated path.
  • The outdated-case test previously asserted against an empty stderr. It now carries brew's real stderr chatter, so a future "stderr means failure" reading fails the test rather than silently regressing.

Verified the suite rejects the naive implementation: replacing the body with if returncode != 0: raise fails test_check_homebrew_update_available_exit_code_1_means_outdated. All three shapes — (0, empty), (1, name on stdout), (1, empty + Error: stderr) — are now covered, with only the third refusing to report "up to date". 24 passed.

groksrc and others added 2 commits August 22, 2026 22:53
The PyPI fallback for a failed `brew outdated` set update_available=True,
and run_auto_update() then proceeded to run `brew upgrade`. That is unsafe
two ways: release.yml publishes to PyPI in the `release` job while the
Homebrew formula job `needs: release`, so PyPI can carry a version the tap
cannot install yet; and whatever hid the brew answer (untrusted tap, brew
missing) also blocks the upgrade itself, so the command is doomed.

Keep the fallback for the negative answer -- the tap can only lag PyPI,
never lead it, so "nothing newer exists" is sound -- but when availability
was inferred from PyPI because brew could not answer, report the update
plus the brew failure and let the user upgrade deliberately.

Reported by Codex review on #1298.

Signed-off-by: Drew Cain <groksrc@gmail.com>
Signed-off-by: phernandez <paul@basicmachines.co>
@phernandez

Copy link
Copy Markdown
Member

Completed the remaining #1297 version-reporting gap in c91190a.

The Homebrew check now uses brew outdated --json=v2, which preserves the real three-way outcome and supplies Homebrew's own current_version. The normal outdated path therefore no longer reports latest: unknown, and it does not need PyPI as a potentially-ahead display source.

Verified against real Homebrew output for an outdated formula, an up-to-date formula, and the untrusted-tap failure. The focused suite is now 31 passing, with Ruff and the repository typecheck clean.

@codex review

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: c91190adbe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@phernandez
phernandez merged commit c5cff99 into main Aug 23, 2026
26 checks passed
phernandez pushed a commit that referenced this pull request Aug 23, 2026
The PyPI fallback for a failed `brew outdated` set update_available=True,
and run_auto_update() then proceeded to run `brew upgrade`. That is unsafe
two ways: release.yml publishes to PyPI in the `release` job while the
Homebrew formula job `needs: release`, so PyPI can carry a version the tap
cannot install yet; and whatever hid the brew answer (untrusted tap, brew
missing) also blocks the upgrade itself, so the command is doomed.

Keep the fallback for the negative answer -- the tap can only lag PyPI,
never lead it, so "nothing newer exists" is sound -- but when availability
was inferred from PyPI because brew could not answer, report the update
plus the brew failure and let the user upgrade deliberately.

Reported by Codex review on #1298.

Signed-off-by: Drew Cain <groksrc@gmail.com>
@phernandez
phernandez deleted the fix/1297-brew-update-false-uptodate branch August 23, 2026 14:54
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.

[BUG] bm update reports "up to date" when the Homebrew check fails (false negative pins users to an old version)

2 participants