Repository navigation
Description
Problem
At intake, only the Python SDK emitted worker and client metrics. The original PHP/Rust metrics feature is now delivered and this issue is closed. The pinned source observations below are historical; current delivery is summarized afterward.
- Python defines six metrics: client requests, worker polls and worker tasks, each with a
_duration_secondshistogram. Worker metrics are taggedtask_kind,task_queueandoutcome. Users plug in a recorder, such as the bundled Prometheus adapter. - The PHP SDK has no metrics recorder. Its worker reports only sticky-cache counters.
- The originally inspected Rust SDK exposed only
StickyCacheMetrics. - The operator envelope names worker SDK metrics, including schedule-to-start latency and poll success, as a runtime telemetry source. The six listed instruments are process observations; they do not establish schedule-to-start latency, durable execution counts or billing units.
The original report was source-verified. Current implementation and runtime evidence follow.
Acceptance criteria
- The PHP SDK and the Rust SDK accept a pluggable metrics recorder on the client and worker, with a no-op default.
- They emit the same metric names, types, units and tag keys as Python, so one dashboard query works across SDKs.
- One shared list of metric names, types, units and tags is published, and each SDK's tests check their output against it.
- Each SDK guide shows exporting the metrics to Prometheus or OpenTelemetry.
Delivered scope
The original acceptance is complete:
- The shared six-instrument contract was published in #245, with baseline JSON SHA256
c456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0. The current registry separately identifies later revisions. - Python's bounded-recorder correction shipped in 2.10.0, with normal registry-installed controls and exporter acceptance and its published metrics guide.
- Rust's pluggable recorder shipped in 4.7.0 through #131, with registry-installed HTTP/Worker/Prometheus acceptance and eight-locale exporter guides.
- PHP's pluggable recorder shipped in 3.8.0 through #214. Its published exporter guide describes the no-op default, client/worker selection and OpenTelemetry adapter. Installed Worker follow-through #394 is closed via Restore the approved PHP 8.3 inputs after both upstream assets return 404 #403; published-package run 43400585178 passed on SDK 3.17.0/native Server 3.8.0, with the retained installed lock and actual worker observations.
The original closure preserved the two then-open revision-2/installed follow-ups. Both are now delivered on their named tuples: PHP's installed follow-through and Rust's 4.16.0 revision-2/Prometheus receipt. Earlier six-instrument receipts do not claim later-revision adoption or qualify newer artifact tuples.
The issue remains closed. Original receipts and failed predecessors remain in the owning history. PR #405 corrects the stale shared README pointer; that documentation correction does not reopen or repeat the delivered feature.
Activity
rmcdaniel commentedon Oct 22, 2026
Scope note: dashboards and alert rules break when a metric or tag key is renamed, so the shared list should say how those names may change. The compatibility page's public surface families don't say whether SDK metric names and tags are stable. The Server's metric series are covered only implicitly, as part of a system route's response.
rmcdaniel commentedon Oct 23, 2026
The shared list is in draft #245. This slice publishes only the common recorder contract: six actual Python names, counter/histogram types, count/second units and exact tag keys. PHP/Rust implementation and all three SDKs' adoption tests and exporter guides remain required. The registry is not evidence that those SDKs emit it.
Product review found an implementation gap relevant to bounded labels: the inspected Python
client.pyat2da02a7ac8a68a7cd4267e86ef10e0198a309592normalizes ordinary activity-task IDs but retains IDs in actual/worker/update-validation-tasks/{id}/approveand/worker/sessions/{id}/heartbeatpaths. I exercised only that exact normalization function with synthetic values, not an installed SDK or live Server. The draft records this honestly and requires placeholder/unknown route values rather than identifiers, query strings, payloads or credentials. This needs a Python owner correction and emitted-value controls before claiming bounded labels.The shared JSON is intended for each SDK's tests to consume at a pinned commit. Stable names/types/units/tag keys need migration-aware major changes; additions and changed tag values need changelog entries. Coordination is being sent to the three existing SDK owners. This audit stays open through actual cross-SDK product delivery.
rmcdaniel commentedon Oct 23, 2026
Delivered #245 at
73e8fc323e4f46322945a007e54a546395904f79, whole treebe3661389c1ceb3ba7759bcef10ced07f1bad937, identical to qualified6e96ec51. All seven candidate and six independent main checks pass, including main contracts and main Sonar. The exact main analysis names that merge. Direct PR review reports zero OPEN/CONFIRMED, and the valid assertion-order finding is CLOSED/FIXED without tuning. This is not a claim that the older project-wide Sonar backlog is empty.The published JSON is independently byte-identical to the tested contract: SHA-256
c456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0. All three SDK maintainers received and acknowledged the immutable commit/hash. Exact verified offline copies are supported. The merged remote head is absent.This delivers only the shared names/types/units/tag keys and compatibility/adoption guidance. Python #205 / #206 owns the actual bounded routes and recorder observations; its publication and installed acceptance remain separate. PHP/Rust instrumentation and installed exporter guidance remain incomplete. Registry publication does not establish cross-SDK parity, so this issue stays open.
rmcdaniel commentedon Oct 23, 2026
Rust implementation is now in draft sdk-rust131, prospective compatible minor4.7.0, exact initial source
149efb74b2e96e26771929ace8f92294ebee7051. It vendors the byte-identical shared JSON at73e8fc3 / SHA256c456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0.Eight actual HTTP/worker controls pass for names/instruments/units/tag keys and paired+1/nonnegative durations, original-plane routing, ID/query/unknown-route privacy, logical transport retry, page-request counting, empty/error/backpressure polls, workflow/activity/query success/failure, recorder inheritance/override and no-op/panic isolation. The optional Prometheus adapter uses the official0.14 client with an application-owned dedicated registry. The expanded query control initially omitted its required workflow registration; the fixture was corrected. A full run also exposed stack pressure in an existing adjacent-condition replay test after request wrapping; boxing the request I/O future fixes that exact unchanged regression without increasing stack limits or altering fixtures. The complete rerun is required and running.
Exact hosted CI/corpus, CodeQL/Sonar, published Server emitted-value qualification, protected publication, normal installed adapter acceptance and published exporter guides remain before Rust delivery. This is source progress only; this shared issue stays open for every SDK's actual delivery. No Server implementation or producer fixture coercion is included.
rmcdaniel commentedon Oct 23, 2026
Rust implementation and normal installed acceptance are delivered as 4.7.0, exact source5e2af20fde934e05bf18f64111dce8e590ea6c90, protected OIDC39947861450 passed. durable-workflow/sdk-rust#131 (comment) records the API/archive/lock checksum, Rust1.86/no source override, preserved security floors, all4 public HTTP controls and fresh published Server2.11.0 all-six-metric/Prometheus acceptance. The released README/runnable adapter recipe is included. All-locale Website exporter guide follow-through remains separate; PHP/Python and the shared issue stay open with their owners. No Server/Cloud or other SDK adoption is claimed.
rmcdaniel commentedon Oct 23, 2026
The Rust portion is fully delivered, including published all-locale exporter guidance.
5e2af20fde934e05bf18f64111dce8e590ea6c90passed protected OIDC publication and normal installed Rust1.86 HTTP/worker/Prometheus acceptance: exact package identities, checksum and installed receipt.04b9b17a9ec2a7314149030762d9594be7600b18, exact all-locale CI39949958605, artifact39950742509 and actual Pages39951424533. The Website owner verified16 live routes, language/canonical/alternate links and mobile light/dark rendering.77692e778f3edfed368ebd771c8402755d71697a481fb79c827b13831ca882d6. The live guide states minimum4.7.0, optional metrics-prometheus, exact names/tag keys, no-op/inheritance/override, request/page/retry observations and application-owned scrape/export lifecycle.The shared issue stays open for the other SDKs and their remaining acceptance with their owners. The selected Server/SDK tuple and other SDK/Cloud adoption are unchanged.
rmcdaniel commentedon Oct 23, 2026
Additional independent Python source-adoption check at the fixed #210 candidate
12b5f3721e99afcfa37558dbcb78676d7bc49575: the vendored JSON is byte-identical to the shared registry, SHA-256c456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0. Its provenance pins shared merge73e8fc3. The SDK tests load that list and compare recorder operations, names, types/units, tag keys, paired +1/nonnegative durations, recorder inheritance/override and the Prometheus adapter.The client/poll/task controls exercise actual recorder hooks with constructed HTTP, poll and task behavior. Source inspection of those controls is not live Server worker qualification. The SDK owner's locally packaged installed receipt remains separate. A fresh PyPI metadata read still reports 2.9.0 and no 2.10.0 release, so normal registry publication/installed acceptance remains pending.
#257 is merged with seven candidate checks and direct Sonar OK/zero unresolved findings; published README/JSON bytes have been independently verified. Its independent main checks are still pending. The guide now preserves the delivered Rust package/guides and other SDKs' remaining delivery; JSON revision and contracts are unchanged. #233 remains open.
rmcdaniel commentedon Oct 23, 2026
Delivered #257, merge
0f4fdb071d0ddff0fb11232760d422005657c372. All seven candidate and six independent main checks pass; direct Sonar is OK with zero unresolved candidate findings and main analysis at this exact merge. Candidatea42d6552a5e0ae3d1f1fc4ca99245e6091aab284and merge share tree7999c1f3be6481e8f3a9e31318ac1b8ddb7c91c4. Published README blob262c78eca74e15c82e3e48ec4fa058d7fc4901ed, SHA-256a9036923a2275fb9960c9931ba3812c7437db8426229f83160f665a3e34f4819, independently matches tested bytes. Completed remote/local heads are retired. JSON revision and SHA-256c456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0remain unchanged.The Python owner identified a newer complete untagged candidate: SDK #213, head
4f853f396dba5a530ef0815509b16bfddaa9ebc3, merge38b5a639262bebcf3fd0e67c6ec42ab16bc3a966. Independent readback confirms equal tree26b7da4ee940bc1706889ca6165eac40b89e67ab, the same shared JSON fixture/hash, passing normal candidate checks plus build-only success, explicit publish skip, and fifteen passing main checks. The owner's artifact receipt records fresh wheel/sdist smoke, 37 installed source/RECORD matches and 272 controls including the actual Prometheus adapter. Those are locally built/installed results, not registry publication or live Server worker acceptance. Earlier #210/12b remains historical; it is superseded as the current complete candidate. PyPI still reports 2.9.0, with no 2.10.0 publication.The PHP owner again confirms metrics implementation/tests/exporter delivery are not yet present. Rust's recorded package and guide delivery remain complete in their scope. #233 stays open for actual cross-SDK product delivery; this README reconciliation does not close it.
2 remaining items
rmcdaniel commentedon Oct 23, 2026
PR #262 is delivered as merge
869a7d2dfa6dc17083ddfe9c0e78352cc1cae9d3. The registry README now links Python's actual published-package acceptance and live exporter reference, while PHP implementation and qualification remain open.All seven checks passed for exact candidate
96a1d28961196ecb2199be4a154eef6de2da3ac5, with direct Sonar OK and zero open/confirmed PR findings. All six independent main checks pass: shared controls, Sonar analysis and three CodeQL languages attached to that exact revision. Direct Sonar analysisca0f3cd5-3c5f-4912-9ced-282511378679identifies869a7d2and reports quality gate OK.The tested/published whole tree is
b969ec8fde2b23060ed4c17c82139e0ee8279f61. Publishedsdk-metrics/README.mdhas blob61e1bc3a93f63ce156daa73247a0359eb0707920, SHA-256c542a0ec841dbb8b862e995c2e33d080acd47c7800855626059e804156079e42. Canonical JSON, its original reference and SHA-256c456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0remain unchanged. Completed branch and source checkout are retired.The actual Python 2.10.0 wheel/tag/module verification and the SDK owner's attributed 334-control registry-installed receipt remain in the current issue description. This documentation change starts no runtime and adopts no SDK in another consumer. #233 stays open for PHP's actual instrumentation, emitted task/fork controls, complete routes, exporter guidance and installed-package acceptance. The PHP owner confirms its separately prepared 3.5.0 failure-reporting release excludes the metrics branch.
rmcdaniel commentedon Nov 4, 2026
General opened the shared revision-2 source contract as draft .github #286, exact
7a91906ece5cd599175a2e08ebcc9c8bc667a6f6. It adds the single dispatch histogram and preserves all six prior metric records/reference. Five focused contract tests, a prior-revision rejection control, JSON and changed-source checks pass; normal CI and independent review are pending.This defines the accepted boundary/clock decision. It is not Server-field implementation, SDK adoption, installed-package or exporter-guide acceptance. Existing revision-1 consumers remain pinned. Server #1015 and flat child-only all keep implementation priority; each SDK retains its own published acceptance.
rmcdaniel commentedon Nov 4, 2026
General open-item pass, November 4. Owner: sdk-php for remaining six-metric adoption; Server/sdk-python for ready-age; General for registry.
Next action: Reconcile PHP instrumentation/exporter/installed acceptance and separate the revision2 dispatch metric from delivered revision1 consumers.
Action taken in this pass: Verified central286 is merged as23f9bc3c and asked PHP plus Server to map remaining implementation evidence; existing Python/Rust publication remains attributed, not rerun or relabeled.
General retains the cross-repository follow-through. Existing operator stops and exact source/release/production gates remain binding; the item stays open until its actual acceptance is evidenced.
rmcdaniel commentedon Nov 4, 2026
Rust portion revalidated in the complete owner pass: delivered. Immutable Rust4.7.0 source5e2af20fde934e05bf18f64111dce8e590ea6c90/archive SHAdc6c0353e940a068f4a71eef8dc516d920c88be34f9c68e205f05ec10c34e65b has normal installation, four public HTTP controls and publishedPHP2.11.0 six-metric/Prometheus acceptance, all-eight-locale exporter guide delivery, and canonical shared JSON SHAc456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0.
I inspected current MetricsRecorder/NoopMetrics and the published delivery record. Current accepted4.12.0 retains that surface; its P0 polling correction does not create a new metric taxonomy or a claim of durable billing/latency units. No old runtime/exporter experiment was repeated. Named remaining owner sdk-php is asked to replace the old214/215 checkpoint with its current hooks/task/fork/exporter/public-installed/guide action and evidence; sdk-python is asked for any remaining current shared-contract gap. General retains parent closure across those independent deliveries.
rmcdaniel commentedon Nov 4, 2026
PHP owner reconciliation: revision 1 is delivered, rather than still being the old draft #215 stage. SDK #214 installed 3.8.0 receipt records normal Packagist source/dist
14340ad7, exact 585-file equality, native 3.0.1 lifecycle and real OpenTelemetry 1.15 exporter acceptance. Owner closure was approved by General. Current source has the client/poll/task instruments and optional recorder/adapters; its pinned six-record JSON still hashes toc456f4f434c601fa26f0caba07ef0fd29f548ca8f5fc29ba2f6430f01e32c0f0.Remaining source is revision 2 dispatch latency. I reread accepted #286/
23f9bc3c; the current shared JSON is revision 2, SHA-256081d98ec6f5f6e3812f81ddbe8d2589d75e7c6e457c580dc6631d7857594516a. PHP still loads v1 and has no dispatch instrument. sdk-php owns a separate v2 adoption slice: retain the old six byte-identical records, support the histogram-only dispatch scope without breaking the current counter/histogram pair loader, consume capability + integer ready_age_ms, preserve real zero, skip invalid/missing values, and test one observation per actual dispatch rather than receipt replay/HTTP retry.Server owner: please link or take the canonical ready-age capability/claim-metadata source slice and return its authoritative fixture/published-artifact gate. sdk-python owner: please return the accepted v2 source/reference controls for portable parity. No worker-wall-clock subtraction or synthetic latency will be substituted. Website owner durable-workflow-github-io: please reconcile the all-locale PHP exporter-guide handoff against the already installed 3.8.0 baseline; the SDK portal's metrics guide exists, while the main website PHP guide has no OpenTelemetryMetricsRecorder example in this read. General owns priority relative to the existing Server holds and cross-SDK closure. No new package/runtime acceptance is claimed.
rmcdaniel commentedon Nov 4, 2026
PHP's next ready source slice is the accepted revision-2 dispatch instrument, after the P2 #303/#304 and validator #305 exact-head CI completed. I have now reconciled the full central23f9bc3c README and Python#264 source proposal: literal Boolean claimed_task_ready_age enables only workflow/activity dispatch observations from integer task.ready_age_ms in0..9007199254740991, preserving zero and excluding query/update-validation, missing/invalid data and HTTP retries. These names come from the accepted shared contract, not an invented Server field.
Owner sdk-php: prepare separate PHP source with the exact revision-2 JSON, preserve the six old records, extend the loader for its histogram-only scope, and add actual-dispatch/capability/type/bounds/recorder-failure/retry controls. A fixed bounded diagnostic may identify malformed metadata without values or task identity. Source documentation must mark it unreleased. Server still owns eligibility-origin/capability implementation, lifecycle vectors and a future published artifact; the source hook does not lift that gate. Python remains the source parity reference. General retains independent source integration and cross-SDK closure. No Server experiment or package action is started.
rmcdaniel commentedon Nov 4, 2026
Source preparation advance retained while honoring General's #300 ordering request: the local separate PHP slice now has the exact revision-2 registry, histogram-only loader/observer path, capability cache from existing discovery/registration, and a workflow/activity dispatch hook without new dispatch I/O. All six prior metric records and the original reference compare unchanged; the vendored SHA-256 is exactly 081d98ec6f5f6e3812f81ddbe8d2589d75e7c6e457c580dc6631d7857594516a.
Forty-nine focused dispatch/client/task/cardinality/real-adapter tests pass on PHP 8.4.27 with 2,041 assertions and no skips. Controls cover zero/bounds/types, unsupported/missing discovery, fixed diagnostics, managed registration, actual query exclusion, original poll identity through transport retry, completion retry without redispatch, recorder/diagnostic failure and inherited-recorder fork isolation. The initial 25-probe unchanged source run exposes 18 missing-observation/diagnostic failures. The first probe incorrectly asserted inside a handler and the first candidate runner discovered on the pre-clone client too late; both setup errors were corrected and excluded. An extended retry probe initially used a stationary fake clock; it was stopped and its sleeper/clock now advance consistently. These are not runtime findings.
Owner sdk-php: finish final countercontrols, changed-source analysis/policy checks and actual dispatch-adapter coverage, then open the separate draft when source ordering permits. General explicitly prioritized #300's source blocker over additional independent PRs; no metrics branch push or PR has been opened. #300's correction is now qualified and its exact Security carry is requested at durable-workflow/sdk-php#300 (comment) . Server eligibility-origin/advertisement, installed tuple and guide acceptance remain owned external follow-through; no runtime run or package action was started. All owned test containers are removed.
rmcdaniel commentedon Nov 4, 2026
PHP source adoption is now separate draft sdk-php#306 at c44c6351eb64c88f2471d27ea2565795695c8e80, base 5777680c, tree c22cf4a0: durable-workflow/sdk-php#306 . This followed the completed and returned #300 Sonar repair/fresh 42-check qualification; General retains the higher-priority #300/#303/#304 integration order.
Final local evidence is 50 focused tests / 2,048 assertions with no skips, including actual OpenTelemetry dispatch-histogram export, plus single-process PHPStan. The exact final 32 dispatch probes fail 22 times against unchanged main and pass with the correction; 10 controls already pass. Canonical revision-2 bytes and the unchanged six old records/reference are verified. The local full corpus-policy wrapper exceeded its 210-second deadline and is explicitly unqualified. Normal PR CI is now providing the required corpus/compatibility/audit gates; no extra matrix, manual retry or Server run is dispatched.
sdk-php owns exact-head CI/source follow-through and any necessary normal base refresh. Security/General own independent source review/integration after those gates; Server retains eligibility-origin/lifecycle/capability implementation and the later published artifact. Installed tuple and all-locale guide acceptance remain open. All owned containers are removed; this source PR is not publication or runtime acceptance.
rmcdaniel commentedon Nov 5, 2026
PHP's ordered metric source is refreshed after accepted #305 in sdk-php #306: head
587f60936e45051db2b4cf774bdd4225e3569435, tree667de10bd81f07fec490358cadd9435fd8af5114, accepted base57a9281e2874f409d6815cb077e6426ae46be486. Original metric scope/delta and canonical revision-2 registry bytes remain intact; fresh hosted checks and independent Security source review are in progress.sdk-php owns findings, terminal qualification and post-integration main/live preservation. Security owns exact-head source review; General owns normal integration and release sequencing. This remains capability-gated SDK source. Server owns the eligibility-origin/advertised-ready-age producer and lifecycle contract; the future native source plan explicitly excludes unfinished ready-age production. No published/installed tuple or all-locale runtime acceptance is implied, and this parent remains open. No new Server run, solve, image build or publication was started.
rmcdaniel commentedon Nov 5, 2026
PHP's capability-gated source is accepted in actual main
63a98e579b580a25bab7e604ca7577badeb0ff3f, exact reviewed tree667de10bd81f07fec490358cadd9435fd8af5114. Owner main/source/live-preservation acceptance records 40 successful normal main checks/two intended skips, successful preview and skipped live deployment. The accepted stable live binding remains6a821568; no package or deployment promotion occurred.The exact revision-2 metrics contract and strict Boolean/integer/bounds/low-cardinality/dispatch-vs-retry/failure-isolation boundaries have independent Security source PASS. PHP's source portion is delivered. Server still owns the ready-age eligibility-origin/producer/capability/lifecycle implementation; General owns its priority and the eventual published tuple, with sdk-php owning normally installed consumer and guide follow-through. The current native source plan excludes unfinished ready-age production. This parent remains open; source acceptance does not establish runtime telemetry correctness or installed/release acceptance.
rmcdaniel commentedon Nov 11, 2026
Server: done. The ready-age producer shipped (server#1030/#1048, capability advertised). Remaining: PHP package and install proof. Owner: sdk-php.
rmcdaniel commentedon Nov 11, 2026
PHP: worker metrics shipped in 3.8.0, and the ready-age histogram in 3.10.0. Remaining: an installed test showing them against a published Server. Owner: sdk-php.
rmcdaniel commentedon Nov 13, 2026
Closing: the original scope is done. Worker metrics shipped in the Rust SDK 4.7.0 (#131) and the PHP SDK 3.8.0 (#214), the PHP revision-2 ready-age histogram in 3.10.0 (#306), and the Server's ready-age producer in server#1030/#1048. Two follow-ups are tracked where the work lives: durable-workflow/sdk-rust#238 (revision-2 histogram) and durable-workflow/sdk-php#394 (installed-package test).
rmcdaniel commentedon Nov 13, 2026
PHP installed-package metrics follow-through is delivered: sdk-php#394 closed via #403. The main published-package run passes at https://github.com/durable-workflow/sdk-php/actions/runs/43400585178 using SDK 3.17.0 and immutable native Server 3.8.0. It verifies all five worker instruments, exact labels, paired counters/durations, one ready-age sample per workflow/activity dispatch and orderly worker shutdown. The runner installs from Packagist without source fallback; its tuple, observations and lockfile are retained for 14 days.