Skip to content

Handle Heroku maintenance status and unknown colors gracefully#1

Open
Montana wants to merge 1 commit into
thoughtbot:mainfrom
Montana:heroku-status-robustness
Open

Handle Heroku maintenance status and unknown colors gracefully#1
Montana wants to merge 1 commit into
thoughtbot:mainfrom
Montana:heroku-status-robustness

Conversation

@Montana

@Montana Montana commented Jul 7, 2026

Copy link
Copy Markdown

Problem

The Heroku adapter only maps the green, yellow, and red status colors. Heroku's status page also reports a maintenance state (blue), and the adapter currently raises a raw KeyError when it encounters it:

Upcheck.for(:heroku).status
# => KeyError: key not found: "blue"

This has three consequences:

  1. Uncaught crash during Heroku maintenance windows. Any blue system makes #status and #components raise KeyError, which is not an Upcheck::Error subclass — breaking the README's promise that "every failure raises a specific subclass of Upcheck::Error", and doing so precisely when a caller is most likely to be checking Heroku's status.
  2. Provider#maintenance? is unreachable for Heroku. Nothing maps to "maintenance", so it can never return true.
  3. An empty status array also raises (KeyError: key not found: nil, via max_by returning nil).

Fix

  • Map blue → page status "maintenance" and component status "under_maintenance", with severity ranked between green and yellow (matching Statuspage's none < maintenance < minor < major convention, so a degraded system still wins over a maintenance window).
  • Add a "Systems under maintenance" description.
  • Raise Upcheck::ParseError (instead of KeyError) with a descriptive message if Heroku ever reports a color the adapter doesn't recognize, keeping the error-contract promise.
  • Report "none" when the systems list is empty rather than raising.

Notes for reviewers

  • I ranked maintenance below minor so that a simultaneous degradation takes precedence in the page-level status; happy to change if you'd prefer maintenance to rank higher.
  • If you'd rather degrade gracefully on unknown colors (e.g., treat them as minor) instead of raising ParseError, that's a one-line change — raising felt more honest for a canonical-vocabulary API, but I don't feel strongly.

Testing

  • New fixture spec/fixtures/heroku/current_status_maintenance.json plus a stub_heroku_body helper for anomalous inline payloads.
  • 8 new examples covering: blue → "maintenance" status and "under_maintenance" components, yellow-beats-blue precedence, empty systems list, ParseError on unknown colors (both #status and #components), the maintenance description, and a Provider#maintenance? integration test.
  • Full suite: 99 examples, 0 failures.

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.

1 participant