Wpcomsh fatal-error: route signature records to /logstash under atomic_extension_conflict

[taipeicoder]

Fixes #

Proposed changes

• Add WPCOMSH_Log::unsafe_direct_log_logstash( $feature, $message, $options = [] ) — a sibling to unsafe_direct_log() that POSTs to https://public-api.wordpress.com/rest/v1.1/logstash instead of /automated-transfers/log, so records can land under their own Kibana feature: bucket rather than the default feature:automated_transfer stream.
• $options accepts:
  • properties — structured key-value data, surfaced under properties.* in Kibana for filter / sort / aggregate (the slot dashboards key off).
  • severity — severity tag (critical / error / warning / info).
  • extra — unstructured context, useful to read on a single record but not meant to drive dashboards.
  • Each is omitted from the wire payload when empty so the index mapping stays clean.
• Internally backed by a separate $logstash_queue; both queues share the singleton instance and the existing shutdown drain (send_to_api() now also iterates the logstash queue and stamps siteurl onto each entry).
• Extracted the duplicated "register shutdown function once" block into a private ensure_shutdown_hook() helper so both log() and log_to_logstash() share it.
• Switch the fatal-error signature emitter in wpcomsh_fatal_log_signature() from unsafe_direct_log() to unsafe_direct_log_logstash( 'atomic_extension_conflict', 'wpcomsh_fatal_signature', [ 'severity' => 'critical', 'properties' => $properties ] ). The signature + decoded parts (signature, kind, slug, extension_version, wp_version, php_version) now live under top-level properties.* so Kibana can filter/sort/aggregate on them directly, instead of being nested under extra.messages[0].extra.* as they were behind the /automated-transfers/log envelope in the parent PR.
• Existing 8 callers of unsafe_direct_log() (woa.php, marketplace, atomic-storage, safeguard) and the wpcomsh_log action are untouched — no signature changes, same payload, same endpoint.

Related product discussion/links

• Follow-up to Wpcomsh fatal-error: emit a transportable plugin/version/core/php signature #48369. The set of fields that gets logged (signature + decoded parts) is unchanged from that PR; only the routing/feature bucket and the field placement (top-level properties.* vs nested extra.*) change.

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

No new data, but the destination bucket and field layout change. The fatal-error signature record introduced in #48369 — signature, kind, slug, extension_version, wp_version, php_version, plus the standard top-level siteurl — now lands in Kibana under feature:atomic_extension_conflict (severity critical) instead of being a wpcomsh_fatal_signature message inside the feature:automated_transfer stream, and those fields live at properties.* rather than nested under extra.messages[0].extra.*. Same fields, same upstream sha256-based 5-min dedup, same caller — only the index bucket / dashboard surface differs.

unsafe_direct_log_logstash() is also available for any future caller that needs its own feature bucket; it bypasses at_options_logging_on like unsafe_direct_log() does, so callers must keep emit rates low.

Testing instructions

1. On an Atomic test site, trigger a fatal from a directory-based plugin or mu-plugin (e.g. drop wp-content/mu-plugins/boom/boom.php containing trigger_error( 'boom', E_USER_ERROR ) on init).
2. In Kibana (log2logstash index), confirm the record now lands under feature:atomic_extension_conflict with severity:critical — not under feature:automated_transfer. Confirm the structured fields are indexed at top-level properties.* (properties.signature, properties.kind, properties.slug, properties.extension_version, properties.wp_version, properties.php_version), filterable / sortable / term-aggregatable directly without an extra. prefix.
3. Verify dedup is still in place: hit the failing site multiple times in quick succession. Confirm only one logstash record is emitted per signature within the 5-minute TTL window (the upstream wpcomsh_fatal_sig: cache gate is unchanged).
4. Verify no regression for existing callers: do something that triggers an existing WPCOMSH_Log::unsafe_direct_log() caller (e.g. an Atomic Storage error event, a marketplace install error, a WoA setup log line). Confirm those records still arrive in feature:automated_transfer as before — same payload, same /automated-transfers/log endpoint.
5. Trigger a fatal with no identifiable file path (e.g. an out-of-memory in core) and confirm no wpcomsh_fatal_signature record is emitted (pre-existing behavior; the upstream wpcomsh_fatal_identify_plugin() returns null and the caller skips the log).

[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 update/wpcomsh-log-logstash-routing 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!

---

Wpcomsh plugin:

• Next scheduled release: Atomic deploys happen twice daily on weekdays (p9o2xV-2EN-p2)

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/wpcomsh/class-wpcomsh-log.php	13/46 (28.26%)	-15.74%	19 💔

Full summary · PHP report

_{Coverage check overridden by I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage. .}