Repository navigation
Separate Rust playground preparation from worker registration #321
Description
Original resulting-main playground run 42103292051/1 failed on 21e28b682dd9da25b5a369e39ae99e8ba375c947 after PHP and Python completed successfully. Rust reached healthy services at 20:27:58 and exhausted the 60-second registration wait at 20:28:59: worker registration did not advertise the current invocation identity and effective types. No Rust worker output or Rust completion evidence was produced. The original failure remains a failure; no rerun has been requested.
The current contract starts cargo run --quiet --locked ... --bin worker inside the registration window. Dependency resolution/application compilation and worker registration therefore share the same 60-second budget, and quiet compilation can leave an empty worker log. This is a concrete diagnostic/phase-boundary gap; the original log alone does not prove whether compilation or registration was the delayed operation. The same unchanged journey passed on the PR head, so this must be resolved before claiming overall main acceptance for #320/#318. The application MySQL concurrent case itself passes on actual main for both PHP versions.
Owner: sample-app. Next action: separate the caller-owned Rust source preparation from registration with a bounded locked two-job build, retain useful build-phase diagnostics, and keep the exact current identity/type registration check and its existing bound. Use existing ordinary source CI for the actual cold journey; no local runtime cell, SDK/toolchain rebuild, new package tuple, image publisher or production action.
Acceptance:
- A bounded preparation phase completes or reports its own original build failure before worker registration begins; descendants are cleaned on timeout.
- The 60-second readiness check remains strict about the invocation worker, workflow and activity types; no stale registration or retry masks a failure.
- Focused source controls cover preparation failure/timeout and ordering, caller-owned source is preserved, and credentials remain role-scoped.
- The existing normal PHP/Python/Rust authored journey provides actual result and cleanup evidence on the resulting source/main. Preserve this original NONPASS separately.
Activity
rmcdaniel commentedon Nov 5, 2026
SDK Rust owner coordination: I searched current and historical SDK registration/startup/compilation/dependency issues and PRs. No matching open SDK 4.12 registration/dependency-startup defect or parallel SDK diagnosis was found. The only open SDK issues are #191/#192 (condition-history installed evidence), and no SDK PR/build/runtime job is active. Sample App retains ownership of this caller preparation/registration boundary; I have not started a duplicate investigation or requested an SDK patch/run.
Historical references are distinct:
=1.26.1; this is not evidence for the current silent deadline miss.At exact published source H,
Worker::run_with_storage_admissionawaits registration before starting the registered poll loop. The original emptycargo run --quietlog does not establish that this SDK registration path was reached, or prove compilation caused the timeout. Your bounded locked caller build followed by execution of the prepared worker separates those observations while preserving the existing exact-identity/types registration deadline. If that later original phase evidence identifies an SDK-level failure after prepared-binary entry, I own the SDK handoff against this same issue; current code/package/runtime gates remain unchanged.rmcdaniel commentedon Nov 5, 2026
Source preparation candidate is draft #322, head
dd3d1ab6d4a0e904ab15592c78a0c64d10994c4a, tree1ac5eaf36fdd19ef83e9e198edf6612effe1dfb4. Four inert process/environment controls and the actual extracted managed-role/order harness pass locally. A pre-existing zero-ms mock timing refusal is retained in the PR attribution and fixed with a deterministic harness clock. Existing ordinary CI is active, including the normal two-architecture untrusted PR image qualification (push: false, read-only permissions); the explicit publisher remains unexecuted. Owner/next action: sample-app will inspect the original build/prepared-worker phase outcome and current required checks, repair concrete source failures, then perform normal green merge/main follow-through. No local Cargo/build/runtime or SDK tuple change.rmcdaniel commentedon Nov 5, 2026
Completed through normally merged #322. The canonical actual-main receipt records original PHP/Python/Rust journey PASS, 50.46s bounded two-job Rust preparation before services/registration, exact invocation completion and cleanup, all focused process/role controls, both native PR-image qualifications, and preserved original NONPASS attribution. Local candidate retained, remote branch absent, actual-main checkout clean. Broader original main checks and the separate future public-image dependency remain owned in #318; no image publication or deployment is claimed.