Repository navigation
Conversation
When a WordPress.com call behind the uptime route fails, the 502 now carries the upstream HTTP status (0 for a transport failure) and, for a transport failure, the WP_Error code and message. This lets a timeout, a 401, and a 500 be told apart when a site reports its uptime history is unavailable, instead of discarding the reason entirely.
Contributor
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Contributor
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
…nto add/protect-uptime-error-detail-JETPACK-2964
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes JETPACK-2964
Proposed changes
Follow-up to the Monitor section added in #53194 — this PR is stacked on that branch and targets it, so it should merge after #53194.
When either WordPress.com call behind
GET jetpack/v4/protect-dashboard/uptimefailed, the route returned a genericuptime_unavailable502 and discarded the reason: the upstream status code and anyWP_Errornever reached the response, so a site reporting "uptime history is unavailable" left nothing to look at.errorstring for a transport failure (theWP_Errorcode and message), instead of collapsing every failure to code0.upstreamStatus(the upstream HTTP status,0for a transport failure) and, for a transport failure,upstreamError. That is enough to tell a timeout from a 401 from a 500.No UI change — the dashboard still shows the same generic message; the detail is for logs and support.
Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
add/protect-dashboard-monitorbranch; review it on top of Protect Dashboard: Add the Monitor section #53194.jetpack test php packages/protect -- --filter Monitor_Test— theprovide_unusable_historiescases now assert the upstream detail on the 502 (a timed-out request, a 500, a 401, a 403, and an empty body each leave distinct data behind).GET /wp-json/jetpack/v4/protect-dashboard/uptimewhile WordPress.com is unreachable (e.g. short-circuit the request to aWP_Erroror a 500). The 502 response body'sdatanow includesupstreamStatusand, for a transport failure,upstreamError.