Skip to content

web: fix /-/ready stopping header and add tests#17795

Merged
bboreham merged 1 commit intoprometheus:mainfrom
chuanye-gao:fix/ready-stopping-header-test
Jan 20, 2026
Merged

web: fix /-/ready stopping header and add tests#17795
bboreham merged 1 commit intoprometheus:mainfrom
chuanye-gao:fix/ready-stopping-header-test

Conversation

@chuanye-gao
Copy link
Contributor

@chuanye-gao chuanye-gao commented Jan 6, 2026 •
edited
Loading

What this PR does

  1. Fixes the missing X-Prometheus-Stopping header issue for the /-/ready endpoint when Prometheus is in NotReady state (previously, the header was never sent for this state).
  2. Adds comprehensive test coverage to verify:
    • X-Prometheus-Stopping: false is returned for NotReady state.
    • X-Prometheus-Stopping: true is returned for Stopping state.
    • Consistency of the above behavior across GET and HEAD requests to the /-/ready endpoint.

Why

The existing tests only asserted HTTP status codes and did not verify the presence or value of the X-Prometheus-Stopping header, which could cause unclear readiness status signals.

Notes

The test assertions are intentionally kept explicit to make the readiness state transitions
(NotReady → Stopping → Ready) and their HTTP behavior easy to read and debug.
If a more DRY-style test structure is preferred, I’m happy to follow up and refactor accordingly.

Which issue(s) does the PR fix:

NONE

Does this PR introduce a user-facing change?

[BUGFIX] Web: Fix missing `X-Prometheus-Stopping` header for `/-/ready` endpoint in `NotReady` state, and add test coverage for header validation. #17795

@chuanye-gao
web: fix ready endpoint stopping header and add test coverage
f13283a 
Signed-off-by: Chuanye Gao <jamesgaoctf@gmail.com>
@bboreham
Copy link
Member

bboreham commented Jan 7, 2026

Thanks for this. Can you clarify please: is this to fix a regression or has it been broken for a while?

@bboreham
Copy link
Member

bboreham commented Jan 7, 2026

Also can you clarify: is this purely to do with tests, or does it change the behaviour seen when calling /-/ready ?

If the latter, NONE is not appropriate; it sounds like a BUGFIX.

@juliusmh
Copy link
Contributor

juliusmh commented Jan 8, 2026 •
edited
Loading

@Apolonia-Vitali-Corleone thank you for the PR. @bboreham This is appears to be a real BUGFIX: when Prometheus is NotReady the X-Prometheus-Stopping header is never sent. See playground. It appears the change was introduced 2 years ago here.

@bboreham
Copy link
Member

bboreham commented Jan 8, 2026

Thanks @juliusmh.

Still trying to get this precise...

  • Fixes the header write order for the /-/ready endpoint when Prometheus is in NotReady or Stopping state.

I see two cases in the code for NotReady and Stopping, and this PR only changes one of them. Would it be correct to say "when Prometheus is in NotReady state."?

I also observe that the UI code seems to only check for X-Prometheus-Stopping: true, and this behaviour is not documented, so this would not be something a user would notice. But it still seems right to call out the fix in the changelog.

@chuanye-gao
Copy link
Contributor Author

chuanye-gao commented Jan 9, 2026 •
edited
Loading

@bboreham @juliusmh Thanks for your suggestions!

Indeed, I only fixed the issue that occurs in the NotReady state. This is a longstanding issue and qualifies as a bugfix. I've updated the PR description accordingly.

bboreham
bboreham approved these changes Jan 20, 2026
View reviewed changes
Copy link
Member

@bboreham bboreham left a comment

Choose a reason for hiding this comment

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

lgtm

@bboreham bboreham merged commit d83e119 into prometheus:main Jan 20, 2026
29 checks passed
krajorama
krajorama reviewed Jan 20, 2026
View reviewed changes
Copy link
Member

@krajorama krajorama left a comment

Choose a reason for hiding this comment

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

lgtm

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

Reviewers

@krajorama krajorama krajorama left review comments

@bboreham bboreham bboreham approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@chuanye-gao @bboreham @juliusmh @krajorama