Connection: Remove includeHealthErrors prop and usage by coder-karen · Pull Request #52977 · Automattic/jetpack

coder-karen · 2026-09-30T10:46:32Z

Fixes CONNECT-463

Proposed changes

Connection: Consume the health check endpoint and show results via the existing error UI - Activity Log initially #50169 added includeHealthErrors so a consumer could show connection health-check failures in the shared connection error notice. Activity Log was the only consumer: it ran the health check when its list request failed. Connection error notices now cover the most important non-token problems directly, through stored xmlrpc_request_blocked and wpcom_ssl_verification_failed errors. The separate client-side health-check path is no longer needed, so this PR removes it.
This PR removes the changes added in the mentioned PR. However we keep runConnectionHealthCheck as a deprecated no-op that resolves with {}. Activity Log bundles its own copy of the connection package, and the connection store is registered by whichever script runs first on the page. An older Activity Log build can therefore run against this newer store, and it calls the thunk without a guard. The stub prevents a crash in that case and can be removed in a later release.

What this means for the Activity Log:

In practice, Activity Log's connection notice now only shows when a stored connection error coincides with a failed list request. Stored errors that don't affect the list's outgoing, user-token-signed request (such as xmlrpc_request_blocked and wpcom_ssl_verification_failed) won't appear there, which fits the notice's "Your activity log couldn't load because…" context. My Jetpack remains the place for site-wide connection state. The <ConnectionError> branch is kept so Activity Log picks up token rejections automatically if they're stored as connection errors in future.

Related product discussion/links

See above Linear link.

Does this pull request change what data or activity we track or use?

No.

Testing instructions

On a Jetpack-connected site running this branch, with Jetpack Debug Tools active (it can be enabled from the Jetpack Beta Tester plugin list):

Activity Log, healthy connection

Visit /wp-admin/admin.php?page=jetpack-activity-log with DevTools open on the Network tab.
The list loads normally, and no request is made to /jetpack/v4/connection/test.

Activity Log, broken user token (no stored connection error)

Under Jetpack Debug › Broken token utilities, choose "Set invalid user token (current user)". The Connection errors view in the debug tool stays empty.
Reload Activity Log. The connection error notice does not show, and neither does the My Jetpack notice. Activity Log shows its own "Couldn't load the activity log: …" notice with the WordPress.com error, as on trunk before Connection: Consume the health check endpoint and show results via the existing error UI - Activity Log initially #50169. There is no /connection/test request.
- Note that this itself can be confusing (eg 'Only Administrators can query information about the current site' when an admin token is broken) but is unrelated to connection errors here.
Reset the token in Broken token utilities (or disconnect and reconnect your user). Activity Log loads normally again.

Activity Log, broken site token

Using the Jetpack debug helper plugin, create a site error on the connection errors page.
The Activity Log page should continue to show logs and no connection error notices, as the log does not require a site connection

Activity Log, broken blog and user tokens (stored connection error and list failure)

In Broken token utilities, choose Set invalid blog token, then Set invalid user token (current user).
Load Activity Log. The list fails; the request's blog-token check stores an invalid_token) error.
Reload Activity Log. The shared connection error notice shows with the "Your activity log couldn't load because your site isn't fully connected to WordPress.com." context line.

Activity Log, list failure with no connection error

Clear any stored errors in Broken token utilities (the Connection errors view should be empty, and My Jetpack shows no connection notice).
With a healthy connection, use the snippet from the original PR - Connection: Consume the health check endpoint and show results via the existing error UI - Activity Log initially #50169 - that returns a non-connection error for the list request (3bcfd-pb), then change the sort order.
The generic "couldn't load" notice shows and the connection notice does not.

Other consumers unaffected

The connection error notice still shows in My Jetpack and Activity Log when a stored connection error exists. For example, use Broken token utilities to generate a sample verified error, then reload both pages. Activity Log shows it only when its list request also fails.

Deprecated stub

On the Activity Log page, run await wp.data.dispatch( 'jetpack-connection' ).runConnectionHealthCheck() in the console. It resolves with {} and makes no network request.
wp.data.select( 'jetpack-connection' ).getConnectionHealthErrors is undefined.

github-actions · 2026-09-30T10:47:51Z

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the remove/connection-include-health-errors branch.
To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack remove/connection-include-health-errors

bin/jetpack-downloader test jetpack-mu-wpcom-plugin remove/connection-include-health-errors

Interested in more tips and information?

In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
Read more about our development workflow here: PCYsg-eg0-p2
Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

github-actions · 2026-09-30T10:48:08Z

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

✅ Include a description of your PR changes.
✅ Add a "[Status]" label (In Progress, Needs Review, ...).
✅ Add testing instructions.
✅ Specify whether this PR includes any changes to data or privacy.
✅ Add changelog entries to affected projects

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:

Ensure all required checks appearing at the bottom of this PR are passing.
Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
You can use GitHub's Reviewers functionality to request a review.
When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
WoA releases happen weekly.
Releases to self-hosted sites happen monthly:
- Scheduled release: October 6, 2026