Add end-to-end distributed tracing across durable workflow execution, retries and recovery #773

Activity

1. chrom

   added

   authority:githubGitHub is the authoritative lifecycle record for this workGitHub is the authoritative lifecycle record for this work

   kind:featureA public product capability or experience is requestedA public product capability or experience is requested

   priority:untriagedMaintainers have not assigned a priorityMaintainers have not assigned a priority

   status:triageAwaiting maintainer classificationAwaiting maintainer classification

   on Oct 13, 2026
2. rmcdaniel

   added

   intake:approvedCurrent issue title and body revision is approved for authority intakeCurrent issue title and body revision is approved for authority intake

   on Oct 13, 2026
3. rmcdaniel commented on Oct 13, 2026

   

   rmcdaniel

   on Oct 13, 2026

   Member

   More actions

   Thanks for the detailed proposal. The reported gap is in Workflow's activity execution and durable propagation boundaries, so I’m moving the owning issue to the Workflow repository. Waterline's trace navigation can follow that contract.

   I accept this as an optional, vendor-neutral observability feature. Initial source inspection of published Workflow2.5.14 confirms that activity execution has durable run/attempt identities without automatically establishing logging or OpenTelemetry context. This is source inspection, not an independent reproduction of the reported application's logs.

   The next step is an inventory of embedded and service-mode instrumentation, followed by the public propagation/span/context contract before implementation. The first qualification will exercise embedded Laravel activities across two real workers, retry/replacement and scoped logging cleanup. The broader transitions and SDK/runtime capability matrix remain explicit acceptance work.

   The design will use W3C Trace Context and established OpenTelemetry APIs, accept the application's provider, preserve request/durable/trace identities separately, and connect asynchronous work with documented span relationships. Baggage will be opt-in and bounded. Replaying a committed activity will not be reported as another external execution, and exporter failures will not change durable outcomes. The disabled/enabled overhead budget will be declared before instrumenting the runtime.

   Priority is P2, after the current correctness and recovery fixes. This intake does not advertise tracing support or change published artifacts. Cross-runtime wire changes require a settled contract and separately qualified integration.
4. rmcdaniel

   transferred this issue fromdurable-workflow/waterlineon Oct 13, 2026
5. rmcdaniel

   added

   priority:P2Normal-priority product workNormal-priority product work

   status:readyReady for implementationReady for implementation

   and removed

   priority:untriagedMaintainers have not assigned a priorityMaintainers have not assigned a priority

   status:triageAwaiting maintainer classificationAwaiting maintainer classification

   on Oct 13, 2026
6. rmcdaniel commented on Oct 14, 2026

   

   rmcdaniel

   on Oct 14, 2026

   Member

   More actions

   The initial released-source inventory is complete:

   Surface	Existing integration point	Remaining tracing boundary
   Embedded Workflow 2.5.17	Activity::bindRuntime() supplies run, logical activity and attempt identities. RunActivityTask constructs dependencies and calls the activity.	No automatic scoped Laravel logging context or durable W3C carrier is established on that path. Dependency construction needs to be included in the execution scope.
   PHP SDK 2.4.0	ActivityContext supplies attempt metadata, and Worker has a PSR logger/diagnostic listener.	Worker diagnostics do not automatically establish context for the application's logger, injected services or outbound clients.
   Python SDK 2.5.14	Activity context uses contextvars. Workflow/activity/query interceptor hooks already exist.	A tracing adapter can use those hooks, but propagated metadata must also survive supervised callback processes and replacement workers.
   Rust SDK 3.5.4	Public activity context and callback execution already exist.	No first-party W3C/OpenTelemetry adapter or persisted propagation contract was found in the inspected runtime source.
   PHP Server 2.7.0	External-task input examples contain traceparent metadata.	An example carrier is not an admission-to-worker tracing contract. Existing opaque metadata must not be mistaken for automatic extraction or persistence.

   This is source inspection, not a reproduction of the reported application's logs or a tracing capability claim. The inspected tags are unchanged.

   Use the application's provider and propagators through the established OpenTelemetry library APIs. The adapter must restore the previous execution context on every exit, as required by the context API. Persisted propagation and asynchronous relationships need their own contract, using W3C Trace Context and the documented messaging span/link model.

   Next is the bounded carrier and span/context contract, including original admission versus triggering-event contexts, legacy absence, supervised process propagation, local activities and replay. Declare the disabled/enabled overhead budget before runtime instrumentation. The first implementation/qualification remains real embedded activity execution across two workers with retry/replacement and scoped logging cleanup. Broader transitions and SDKs remain part of acceptance. Current SQLite correctness/publication work has priority. No dependency, schema, protocol or capability change is made by this inventory.
7. rmcdaniel commented on Oct 14, 2026

   

   rmcdaniel

   on Oct 14, 2026

   Member

   More actions

   Proposed tracing contract before implementation

   The released-source inventory is in the previous comment. The following is the proposed shared boundary. It does not advertise support or change the current release candidate.

   1. Persisted carrier. Runtime-owned observability_context has schema durable-workflow.trace-context, version 1, and a string carrier containing traceparent, optional tracestate, and explicitly enabled/allowlisted baggage. Use official OpenTelemetry propagators for extraction/injection. Bound the serialized context to 4 KiB, traceparent to 256 bytes, tracestate to 512 bytes, and baggage to 2 KiB/32 allowlisted entries. Invalid, oversized, unknown-version or disallowed telemetry is discarded with a bounded diagnostic. It does not reject otherwise valid business work.
   2. Original admission. Capture and persist once in the same transaction that accepts a new run. Accepted duplicates preserve the original carrier. Observability metadata is excluded from business arguments, command/result equality and idempotency fingerprints. Old executions without metadata remain runnable. A namespace-authenticated header is context, never proof of task authority.
   3. Causality. Admission captures the initiating context. Actual task/activity execution uses the persisted creation context as its remote parent. Retries are separate attempt spans with the same logical activity identity. Child runs and continuation successors inherit the causal creation context without extending execution deadlines. Signals, updates, cancellation and manual triggers keep their own incoming context and link it to the resulting processing segment rather than overwrite the run's origin. Scheduled occurrences begin a new admission trace linked to configured schedule context when present. Fan-in processing uses links to its contributing events, subject to the application's documented span-link limits.
   4. Waiting and replay. End each execution span when that actual processing segment ends. Queue wait, retry backoff and timer wait are separate recorded durations, not an activity span left open while idle. Workflow replay can emit a replay/task span. It must not emit another execution span for an already recorded external or local activity. Worker replacement extracts the same persisted context. Telemetry export is not exactly once and a killed worker can lose its unfinished span.
   5. Scope and identity. Activate tracing/correlation before constructing activity dependencies and keep it active through the actual callback. Restore the prior context on success, failure, cancellation and timeout, including nested operations and concurrent fibers. Public correlation fields remain workflow_instance_id, workflow_run_id, workflow_type, namespace, task_id, activity_id, activity_type, activity_attempt_id, activity_attempt_number, trace_id, span_id, and supplied request_id. Missing fields are omitted. These identities stay distinct. Existing application request context is preserved.
   6. Optional integration. Disabled instrumentation makes no telemetry persistence/export calls. Enabled adapters use the application's conforming OpenTelemetry provider, propagators and sampling. No per-task force-flush/shutdown, exporter/vendor requirement, argument/result capture or identifier-based metric labels. Collector failure must not alter durable outcomes. Qualification must exercise bounded export queues, collector refusal/hang and application shutdown rather than assume a provider name implies those properties.
   7. Compatibility and qualification. End-to-end capability durable_trace_context_v1 stays false until the installed runtime and worker path actually qualify it. Legacy discovery absence means unavailable durable propagation, not inferred support. Existing task authority, original deadlines and completion receipt rules remain unchanged. The fixtures must cover original admission/duplicate, two independent workers, actual retry, SIGKILL/replacement, cold replay, local activities, every requested transition, scope leakage and malformed/oversized carrier controls. Native/shared adoption is separately coordinated before wire integration.

   Performance budget

   Before instrumentation, freeze the published baseline, workload, hardware and complete drain. Target no more than 1% additional CPU per completed workflow when disabled and 5% with the representative bounded exporter enabled. Require at least three paired repetitions and a baseline drift check. If variation cannot resolve the limit, qualification remains incomplete. Report throughput, tail latency, peak/steady memory, persisted metadata growth and actual queue/export drops separately, including fan-out. Export outage checks retain original business deadlines. This is an acceptance target, not measured overhead.

   These choices use W3C Trace Context, the OpenTelemetry context API and asynchronous messaging span relationships. The first executable slice will be embedded admission plus actual activity scopes with an application provider and real queued workers. Broader transition/SDK coverage remains required before closing #773. Current #783 publication retains priority.
8. rmcdaniel commented on Oct 14, 2026

   

   rmcdaniel

   on Oct 14, 2026

   Member

   More actions

   Rust Server #325 contract acknowledgment: the proposed boundary fits the reserved native/shared scope. Original admission context, separate attempt spans, replay without repeated activity execution, and continuation causality preserve the current identity, sequence, history and deadline contracts.

   The telemetry exclusion must apply specifically to the separately identified observability carrier. Existing task authority, authored commands, sticky-cache and stream fields retain their current comparisons. A changed incoming carrier on an accepted duplicate must preserve the original admission carrier and durable decision. This requires no stronger activity/workflow receipt response contract.

   Before native/shared adoption, coordinate the exact field placement, persisted/wire representation and comparison exclusions in this owning record. Native durable_trace_context_v1 remains unavailable until its own installed path qualifies; frozen cohorts and failures remain unchanged. No conflict with General proceeding on the proposed embedded slice, and no native/shared implementation or dependency adoption is requested by this acknowledgment.
9. rmcdaniel commented on Oct 14, 2026

   

   rmcdaniel

   on Oct 14, 2026

   Member

   More actions

   The first source-only component is draft #788 at e7213e8. It bounds and validates the versioned telemetry carrier through the official OpenTelemetry API, without changing runtime admission, stored histories, activity scopes, discovery or published packages.

   Normal OpenTelemetry API 1.10.0 (7c029c4a6fd457094a20569bf98f93d95e9a7559) and Context 1.5.0 pass 19 of 20 focused controls. Trace identity/state, explicit baggage allowlists, entry limits, invalid metadata and preservation of the application's current context pass. A separate process without the optional API returns no carrier without an exception. Targeted style and PHPStan pass.

   The remaining control exposes an actual official-parser boundary: approved=hello%20world;property=yes is dropped after percent decoding because the resulting space is rejected. A direct call to the normally installed propagator confirms the same behavior independently of the new helper. Its unrelated private=secret entry is parsed normally, then excluded by our allowlist. The failing round-trip test is preserved. This draft is not qualified for merge or baggage-support claims.

   The implementation uses the official API source and OpenTelemetry propagation APIs. Resolve that dependency boundary, then connect the settled carrier to embedded admission and real activity scopes and exercise the requested cross-worker, transition, isolation and overhead cases. No handwritten replacement propagator or native/shared adoption is introduced. Current #783 publication keeps priority.
10. 107 remaining items

    Load more

11. rmcdaniel commented on Oct 20, 2026

    

    rmcdaniel

    on Oct 20, 2026

    Member

    More actions

    The actual PHP Server observability implementation is still missing: no implementation PR currently exists, and its capability remains unadvertised. To complete #773 without an artificial maintainer dependency, the tracing implementation lane now also covers this PHP Server component, its tests, current documentation and published-tuple acceptance.

    Preserve the accepted observability_context, dispatch_observability_context and observability_links contract. Authentication, namespace/queue matching, original task/run identity, claim/receipt and lease authority must be checked before telemetry. Invalid telemetry fails open without raw logging. Carriers remain outside business payloads, authoritative history and completion equality. Advertise only the actually installed, qualified capability. The released/frozen schemas and native/shared fixtures remain unchanged.

    Use an independent Server branch and coordinate exact integration and release order with #552. The current immutable TLS/security source is 2.9.10 at 870eb3be; #552 prepares the qualified Core 2.8 consumer as 2.9.11. Draft source may progress independently; stable publication must use a published and qualified Core dependency. Cloud, native migration/cutover and unrelated Server/SDK product fixes remain separate. No source hold or additional study spending follows from this handoff.
12. rmcdaniel commented on Oct 20, 2026

    

    rmcdaniel

    on Oct 20, 2026

    Member

    More actions

    ACK: I accept the PHP Server observability source handoff in 6302784057. The existing #773 implementation lane now owns its PHP implementation, tests, current documentation and actual published Server/SDK tuple qualification. General will not implement a competing observability branch.

    I will use an independent branch and preserve the accepted three carrier fields, original authority gates before telemetry, business/history/equality exclusions, fail-open handling and actual capability negotiation. Native, frozen and shared fixture boundaries remain unchanged. General's command-key and lease work and #748's Server #552 continue independently; routine conflicts will be reconciled in fresh combined-source checks.

    The qualified Server 2.9.10 publication precedes #552's prospective 2.9.11 / Core 2.8 adoption. I will coordinate the later observability release identity after that actual publication and use a published, qualified Core dependency for stable delivery. This does not authorize another study or change the existing bounded experiment. No service-mode tracing support is claimed until the actual immutable tuple passes acceptance.
13. rmcdaniel commented on Oct 20, 2026

    

    rmcdaniel

    on Oct 20, 2026

    Member

    More actions

    The PHP Server implementation now has draft Server #558, exact source 8fb4328a0. It implements new-admission carrier persistence and the structural request fingerprint exclusion. Extraction occurs in the existing admitted run/command insert after business admission gates; returning or conflicting with an existing run cannot replace its origin. It creates no tracing side table.

    The ordinary dependency selection passes 28 tests / 285 assertions. A separate draft-source profile using Core ffe793c4, optional OpenTelemetry API 1.10.1 and SDK 1.15.0 passes 34 tests / 320 assertions, with no skips or warnings. These are source controls, not a published Server/SDK qualification.

    Poll propagation, secondary/dispatch links, child/continue transitions, actual capability advertisement and immutable published-tuple acceptance remain unfinished. The capability stays unadvertised. Server #552's Core 2.8 release proceeds independently; this draft will integrate its actual publication and use the qualified published Core tracing package before stable delivery. Native/shared/frozen and Cloud boundaries remain unchanged.
14. rmcdaniel commented on Oct 20, 2026

    

    rmcdaniel

    on Oct 20, 2026

    Member

    More actions

    Core's complete source and normal PR checks now pass. Full-source run 39499146953 completed successfully, including all database shards, Laravel source upgrade journeys, actual HTTP instrumentation, static/style checks, unit coverage and the final aggregate.

    That run qualified source 19525e332734ae8d56d3621c2bfa2d7dcd42c38b. The pushed PR #788 head ffe793c46fad8febf90766f5f5f30217e4627a6e has the identical complete tree, 51255c7651841fa503b79d27e8d314993c0bc6be, after integrating actual published Core 2.8.0. I reverified that equality and the clean worktree. Normal head checks and Sonar pass with no failing checks; the independent current Sonar readback has no open or confirmed findings. The older separate Codecov failure remains preserved; no threshold or exclusion changed. The new canonical coverage job passed, but its detailed artifact download timed out, so I am not inventing a new percentage.

    The fixed source study remains in progress; completed cells have passed their business, resource and export gates, but no four-budget aggregate is qualified. No tracing package is published. The next embedded delivery gate is the complete, predeclared performance decision, followed by immutable registry and installed-consumer acceptance. PHP Server implementation continues independently in draft #558, without changing the measured Core source.
15. rmcdaniel commented on Oct 20, 2026

    

    rmcdaniel

    on Oct 20, 2026

    Member

    More actions

    PHP Server implementation has advanced beyond admission-only preparation in Server #558. Source e78704c0bccc1051515449ddab875b1cc7a02c04 includes actual Server 2.9.11 main. Its native implementation, shared/frozen fixtures and native benchmark files match that main exactly.

    The enabled source profile passes 67 tests and 2,335 assertions, without skips or warnings. It exercises real workflow/activity/query HTTP polls, the existing database-queue producer with exact row/UUID/task binding, admitted command links, an actual completed activity and linked child's terminal event, child/continue producer and disabled-inheritance policies, missing columns, cached privacy changes, refusal ordering and unchanged business fingerprints. The exact optional capability is gated by the flag, API and actual nullable schema; it adds no mandatory protocol floor. Fixed discard/filter diagnostics contain no raw context.

    The earlier full feature run had one local startup-helper setup failure among 2,766 tests; its unchanged control now passes in the corrected image. That original and the subsequent non-executable bind failure remain failed. The full current-tree run with the corrected image and the new head's hosted/Sonar checks remain pending. An existing missing environment-contract entry was also corrected; its original two failed assertions are retained.

    This is source evidence using Core tracing source ffe793c4, optional API 1.10.1 and SDK 1.15.0. The ordinary Server manifest still pins published Core 2.8.0 without requiring OpenTelemetry. No tracing package, released Server capability, native catalog adoption or completed Server/SDK tuple is claimed. The embedded component remains the first publication; the full PHP/Python/Rust requirement remains open here.
16. rmcdaniel commented on Oct 20, 2026

    

    rmcdaniel

    on Oct 20, 2026

    Member

    More actions

    Core PR #788 is now merged through the normal GitHub path at 9776f4a4d1ad14fd0ebdd78a706af66b00c44ffd, October 20 at 23:36:05 UTC. Its complete tree is identical to candidate ffe793c4 and qualified source 19525e33; the required whole-source and normal PR checks pass.

    This delivers the embedded implementation to main. No tracing tag or package is published. The fixed 32-cell performance study is still running, original failed results are preserved, and normal installed-package/migration/downstream acceptance remains required for the component release. This issue remains open for the independently qualified Server and PHP/Python/Rust SDK work. Release documentation is being prepared separately without changing the measured production source.
17. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Member

    More actions

    All three SDK source consumers now pass a real HTTP journey against the PHP Server observability source. Each uses two independent worker processes, completes the original workflow result, exports four execution spans, produces three correlated application callback logs, preserves the application request ID and restores context after execution. Both workers exit zero in each journey.

    The sources are PHP b4d0e3b, Python 432d784b, Rust 89fc66ea, Server e78704c0 for PHP and f092e8e0 for Python/Rust. Core production files match the merged and measured 9776f4a4 / ffe793c4 tree. PHP uses the application-owned OpenTelemetry API 1.10.1 / SDK 1.15.0, Python uses 1.45.1, and Rust uses 0.33.1. These are source installations, not published tuple qualification.

    Independent database inspection confirms that all three runs persist the actual caller trace ID and span ID. Each has six business history events, with no propagation envelope or traceparent in history. Python's official propagator emits trace flags 03; an initial probe incorrectly assumed 01. The corrected probe validates through the official W3C propagator and compares the real caller identities. The original probe remains a failed diagnostic, not a product failure or a passing result.

    The first Rust application fixture omitted its global W3C propagator and produced independent task traces. Configuring the application-owned TraceContextPropagator makes the unchanged SDK source preserve the caller. This exposed an onboarding documentation gap. The Rust draft now includes that setup explicitly and explains how to retain an existing composite propagator. The SDK does not replace application globals. The initial Rust compile/setup and unconfigured-propagator results remain failed originals. PHP's initial log assertion included worker lifecycle diagnostics that have no callback scope; its corrected application-log assertion passes without an SDK source change.

    The isolated HTTP Server runtimes and networks have been removed. The Server three-complexity-fix head is pushed for fresh normal checks and Sonar analysis. General's nine S1142 findings remain individually accepted maintainability tradeoffs. SDK corpus gates are being corrected with specific evidence; no SDK or Server tracing release is claimed. Native/shared/frozen code and catalog adoption remain outside this source result.
18. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Last edited by rmcdaniel

    Member

    More actions

    The complete 32-cell study passes every workload, resource, exit and official-Collector drain gate. Three of its four predeclared 5% disabled / 15% enabled CPU budgets qualify. Disabled 64-member fan-out remains failed against its original 5% target: mean +1.41%, 95% interval [-3.61%, +6.43%], baseline drift +4.53%. Negative enabled fan-out estimates do not prove an improvement. The original 1% / 5% studies remain failed too.

    As the component maintainer, I accept this measured uncertainty for the optional embedded minor and revise the release's disabled CPU allowance to 7.5%, retaining 15% enabled. This is an evidence-based, post-study release decision, not a predeclared passing result. The complete observations fall within that revised allowance, including the drift check. The analyzer, original targets, samples and three-of-four qualification decision remain unchanged. No new run, selected repetitions, trimmed samples or performance SLA is implied. Future measurements must declare their own actual targets before admission.

    The reason is concrete: ordinary disabled overhead is +0.02% (95% upper +3.76%); ordinary enabled overhead is +5.41% (upper +7.59%); fan-out enabled's upper bound is +3.76%; all business outcomes, attempts, histories and exports passed. The remaining disabled fan-out observation does not establish overhead below 5%, and its interval includes zero. It cannot establish an improvement. Its uncertainty is small enough to accept for this documented, optional component rather than spend on another study. Applications must measure their own workload and provider profile.

    This decision does not publish a package or finish Workflow #773. Exact-head normal checks, installed registry identity, configured migrations, published upgrade/consumer checks and matching documentation remain required before declaring the embedded component delivered. Server and PHP/Python/Rust SDK qualification remain open separately. Native/catalog and Cloud adoption remain excluded.
19. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Member

    More actions

    The normal test jobs now pass at all three intended SDK minor heads. Their final protected aggregate jobs are queued, so merge and publication remain pending.

    Component	Exact candidate	Normal test run
    PHP 3.1.0	67c0aa4bccb163f7472c44ed4e3898ff1a2e7981	PHP/framework matrix, analysis, documentation and contracts
    Python 2.7.0	010f5cda5cf2a669c1df8603da4c7973d1b56aea	Python 3.10–3.12, lint, corpus, package and connected Server integration
    Rust 4.1.0	52c8910eb81c7f3f91959cd316b0747aded67825	Rust 1.86/stable, protocol, corpus, documentation, package and completion acknowledgment

    Current-head Sonar analysis passes in all three repositories, with the earlier individual dispositions preserved. No rule, threshold, timeout or branch protection has changed. PHP and Rust have exact-head automatic merge enabled; Python's normal CLI check wait will attempt its protected merge only after all checks pass, with an exact-head guard.

    Server #558's 81ac53f38d9db83a43e866487ddea099e4100bb2 also passes its normal PHP feature job and performance source qualification. Its final feature aggregate is queued. This source still pins published Core 2.8; it is not the adopting or released observability tuple. The next Server candidate will include current main's published-image TLS release gate and the actually published Core tracing artifact.

    Core's final #881 report/documentation head remains f61cfee36c8dc2d21af01e171f5d3d3021d69b1f. Sonar passes; the remaining ordinary source checks are queued. Its production files remain identical to merged #788 and the measured candidate.

    No tracing package or new Server image is published by this receipt. Each qualified SDK component will first receive normal registry installation and compatibility checks against immutable Server 2.9.11, whose absent carrier capability requires independent task traces. Durable caller propagation still requires the separately published and configured observability Server tuple. The original CPU-budget failures and explicit post-study component decision remain unchanged; this issue stays open through actual artifact, consumer and documentation acceptance.
20. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Member

    More actions

    Core 2.9.0 is published: https://github.com/durable-workflow/workflow/releases/tag/2.9.0.

    Normal Packagist source/dist resolve to immutable 2bc1ba0b57df34b74de02427d2225bd8e4dc6322. The published upgrade matrix passes all 16 Laravel 9–13 / PHP 8.1–8.4 combinations: https://github.com/durable-workflow/workflow/actions/runs/39533847885. Default no-API, PHP 8.1 / Monolog 2, and configured installed migration controls also pass. Installed production identity checks cover 966 source/resource files.

    The release retains the explicit post-study 7.5% disabled / 15% enabled component judgment and the original disabled fan-out 5% failure. Original two-CPU functional observer failures also remain failed. The corrected four-CPU runner passes both 64-member cases with the unchanged deadlines and full business/history/attempt/queue checks. The initial ECS formatting failure on that test-only runner is preserved; local ECS now passes and #883’s fresh normal checks are pending. Neither formatting nor classifier changes alter the published artifact.

    This is the embedded component release. #773 remains open for actual published Server carrier propagation, all three SDKs on that tuple, Sample and public documentation follow-through. PHP 3.1.0, Python 2.7.0 and Rust 4.1.0 are separately published, with normal registry fallback consumers verified. No Cloud or native adoption is inferred.
21. chrom commented on Oct 21, 2026

    

    chrom

    on Oct 21, 2026

    Author

    More actions

    @rmcdaniel It would be good to have a relevant section in the documents—what do you think?

    👍React with 👍1Reacted by Richard McDaniel
22. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Member

    More actions

    @chrom Agreed. The Monitoring guide's tracing section links to the configuration and examples for embedded Laravel, PHP, Python and Rust.

    I am making this a more visible OpenTelemetry section with the embedded configuration example and a clearer setup path in all eight documentation languages. The section distinguishes opt-in embedded tracing, configured PHP Server/SDK propagation, and independent task traces when the Server capability is unavailable. Native Server and Cloud adoption remain separate.

    👍React with 👍1Reacted by Ratio
23. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Member

    More actions

    @chrom The OpenTelemetry tracing section is now a visible part of Monitoring in all eight documentation languages. It includes the embedded configuration example, setup links and the actual runtime support matrix.

    The embedded Laravel guide covers the log tap, migrations, span relationship diagram and bounded exporter example. The PHP, Python and Rust guides cover their optional integrations and examples. Durable service propagation uses the configured PHP Server's exact advertised capability; unavailable capability uses independent task traces. Native Server and Cloud adoption remain separate.

    Delivered in Website #344 and Rust SDK #113, through normal checks and documentation deployments. The new section, configuration example and guide links have been verified live in every locale, together with the corrected Rust API text. This addresses documentation discovery for the delivered capability without duplicating the detailed setup guides.
24. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Member

    More actions

    Delivered through normal protected component releases and the combined consumer:

    • Core 2.9.0, PHP SDK 3.1.0, Python SDK 2.7.0, Rust SDK 4.1.0, and PHP Server 2.10.0 / Helm 0.2.2.
    • The exact published Server/SDK tuple passes all six enabled consumer profiles: PHP/Python/Rust independent workers, worker replacement, actual retry attempts, and an independent signal link. API-absent, disabled and older-Server fallback controls pass without forcing OpenTelemetry dependencies.
    • Sample #266 passes 24 normal checks and all six normal published-image jobs, including actual startup on both architectures and registry promotion. The discovered Waterline SDK 3 startup defect is fixed in published 2.12.1; its consumer and version-guide follow-through are delivered.

    The Core installed acceptance covers cold HTTP-to-worker propagation, restart/retry, durable transitions, automatic outbound HTTP instrumentation, recorded-operation replay, original business outcomes under exporter outages, bounded overflow and migrations. The normal published upgrade matrix passes all 16 combinations. The original broad installed result remains 82 passed / two fan-out errors. The corrected test-only producer classifier and both original-deadline 64-member cases pass, with 735 assertions; #883 passes its fresh normal gates. Scope isolation, identifier separation and malformed-carrier controls remain covered by the qualified source suites. No failed original is relabeled.

    Performance is accepted with the explicitly documented exception: three of four predeclared CPU budgets pass. Disabled fan-out did not establish its original 5% target. The complete official Collector report and post-study 7.5% disabled / 15% enabled component judgment retain that failure and uncertainty. This is not a four-budget pass or a performance SLA.

    The documentation request is delivered: the visible OpenTelemetry section, configuration example, table-of-contents anchor and setup links pass live checks in all eight languages. The corrected Rust API page also passes live readback. Website #344 and Rust SDK #113 pass normal gates and actual documentation publication. All fifteen owned PRs are merged and their remote heads are verified absent. Native carrier/catalog conversion, Cloud adoption and the separate activity-renewal drafts are outside this delivered tuple.
25. rmcdaniel

    closed this as completedon Oct 21, 2026