[rmcdaniel]

Part of #325. Native now ignores a caller's optional trace context where PHP Server admits it, so the context can no longer cause a business request to be refused.

Why

PHP Server's optional tracing (#558, Workflow #773) admits a top-level observability_context on start, signal, update, cancel and request-cancellation requests when it is enabled. Published PHP 2.5.14 ignores that field, and so does PHP with tracing disabled. Native refused it with 422 unsupported_request_field. A caller that sent the field without checking discovery would therefore have its start, signal, update or cancellation refused by native.

Change

• The nine native handlers for those operations (current-run and selected-run forms) drop exactly that top-level field before reading the request.
• Native does not validate, store, log or compare the field. A retried start with a different trace context is therefore the same request.
• Native never advertises worker_protocol.server_capabilities.observability_context.
• Terminate, every other route, the same name anywhere else in a body, and any other unknown field keep their existing handling.

Tests

• trace_carriers sends each of the nine routes, with and without a carrier, to two identical workflows. It checks four things:
  • equal outcomes;
  • equal history event types;
  • no stored trace identifier in the description, observation or history;
  • a refused carrier on terminate, and a refused unknown field beside the carrier.
• I removed the change from each of the nine handlers in turn. The test failed every time.
• The test passes on SQLite, PostgreSQL 17 and MySQL 8.0. The full SQLite execution suite passes.

The takeover decision for PHP 2.10 databases that have Core 2.9's carrier columns is recorded on #325. It is not part of this change.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud