Wpcomsh fatal-error: log deactivate clicks; stamp atomic_site_id

[taipeicoder]

Fixes #

Proposed changes

Follow-up to #48401. Two related additions to wpcomsh fatal-error telemetry:

• wpcomsh_fatal_deactivate event. When a logged-in admin clicks the Deactivate button on the fatal-error screen, the signed deactivator endpoint (fatal-plugin-deactivator.php) now emits a wpcomsh_fatal_deactivate event via WPCOMSH_Log::unsafe_direct_log_logstash() before persisting the option update. Pairs with the existing wpcomsh_fatal_signature event so we can tell which fatals lead to user-initiated deactivations vs. recovery-mode entry vs. abandonment. Logged via WPCOMSH_Log's shutdown drain, which runs after the redirect's exit — the queued payload still ships.
• properties.atomic_site_id on both events. Both wpcomsh_fatal_signature (existing) and wpcomsh_fatal_deactivate (new) now stamp properties.atomic_site_id, sourced from the ATOMIC_SITE_ID constant first (avoids an apply_filters() dispatch on the common path) and falling back to wpcomsh_get_atomic_site_id() when the constant is undefined. Stamps are skipped when the resolved id is 0 (off-Atomic / unresolved).

Implementation notes

• The previous single-purpose wpcomsh_fatal_log_signature() was refactored into wpcomsh_fatal_log_event( \$plugin, \$message ) so both events share the signature / dedup / properties pipeline. The dedup cache key now includes the message (wpcomsh_fatal_event:HASH(message|signature)) so a recent signature event for an extension doesn't suppress the matching deactivate event.
• The deactivator endpoint runs at mu-plugin load time, before wpcomsh.php line 28 loads constants.php, so WPCOMSH__PLUGIN_DIR_PATH is undefined when it fires. Manual requires now resolve the wpcomsh root via `dirname(DIR)` instead, which is correct in both the deactivator path and the fatal-screen render path.
• The wpcomsh_get_atomic_site_id() fallback is wrapped in try { … } catch ( \Throwable ) because the helper runs the wpcomsh_get_atomic_site_id filter — a misbehaving callback must not bubble out of a best-effort logger.

Related product discussion/links

• Follow-up to Wpcomsh fatal-error: pass site_url as a property; drop unused /logstash siteurl #48401 (which is itself a follow-up to Wpcomsh fatal-error: route signature records to /logstash under atomic_extension_conflict #48399 / Wpcomsh fatal-error: emit a transportable plugin/version/core/php signature #48369).

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

Yes — additively. Two new fields ship in the feature:atomic_extension_conflict log stream:

• A new event message, wpcomsh_fatal_deactivate, fires only when a logged-in admin (passing the existing deactivate_plugin capability check + HMAC signature on the deactivator endpoint) clicks Deactivate on the fatal-error screen. Payload shape mirrors wpcomsh_fatal_signature: signature, kind, slug, extension_version, wp_version, php_version, site_url, plus the new atomic_site_id.
• properties.atomic_site_id (integer site id from the ATOMIC_SITE_ID constant or wpcomsh_get_atomic_site_id() filter) is stamped on both events. This is the same site id already exposed at `atomic_site_id` in the feature:atomic_global_styles_gate payload elsewhere in this plugin — no new per-site identifier is being introduced, just included on these two records.

Both fields are non-PII server-side metadata about the site itself. No user-level data is collected.

Testing instructions

1. On an Atomic test site, trigger a fatal from a directory-based plugin (e.g. drop a boom/boom.php containing trigger_error( 'boom', E_USER_ERROR ) on init).
2. Visit the site as an admin and confirm the fatal-error screen renders the Deactivate action.
3. Open the wpcomsh log stream (feature:atomic_extension_conflict) and confirm the initial wpcomsh_fatal_signature record now carries properties.atomic_site_id alongside the other indexed fields.
4. Click Deactivate. You should land on wp-admin/plugins.php?wpcomsh_deactivated=…. In the same log stream, confirm a wpcomsh_fatal_deactivate record arrives with the same signature / slug / kind / extension_version as the corresponding fatal record, plus atomic_site_id and site_url.
5. Verify dedup. Re-trigger the fatal within 5 minutes and confirm no duplicate wpcomsh_fatal_signature row arrives. Re-submit a deactivate form within the same window and confirm no duplicate wpcomsh_fatal_deactivate row arrives. The two events do not dedup against each other (the cache key includes the message).
6. Verify off-Atomic safety. On a non-Atomic dev site (no ATOMIC_SITE_ID constant, no wpcomsh_get_atomic_site_id filter), trigger a fatal and confirm the event payload omits atomic_site_id rather than emitting 0.
7. Verify deactivator load order. Confirm the deactivator path (POST to home_url('/') with wpcomsh_deactivate=…&wpcomsh_sig=…&wpcomsh_exp=…) still completes the redirect normally and produces a wpcomsh_fatal_deactivate log row, even though it runs before constants.php loads WPCOMSH__PLUGIN_DIR_PATH.

🤖 Generated with Claude Code

[github-actions]

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 (WordPress.com Site Helper), and enable the add/wpcomsh-fatal-error-deactivate-log branch.

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]

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:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. 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!

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report

[arthur791004]

👍