Handoff: Resolve the provider connection error blocking BuildTest verification

Written: 2026-10-19T09:04:52.893994+00:00

RE-VERIFY: This is a write-time snapshot. Recheck the run at https://buildtest.kotlin.build/run?id=dda1c35b and current BuildTest API status before acting. Results snapshots can be stale; the WUI reported cached-view rebuilding during this effort.

Design decisions in force

2026-10-19: The originating review brief says "Do not weaken anything or change timeouts" and "Leave it draft. Do NOT merge or enqueue." No production deployment is authorized by this record.

Mission summary

Restore the existing provisioning path so BuildTestEmbedded review verification can run. This blocker was found while checking two test-diagnostic changes for https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/1530 . It is separate from whether those assertions are correct.

What was observed

The fixed-source eight-test run failed before execution. Its native client XML has remote-failed=true and a remote-run-error, plus eight zero-time placeholder rows. Fresh run status reports 0 passed and 0 failed of 8. These are eight unexecuted tests, not eight failing assertions.

Exact remote failure:

Remote build failed for runId=dda1c35b: Provisioning deadline exceeded for runId=dda1c35b: elapsedMs=600462 limitMs=600000 firstAdmissionAt=1792399623541 currentAttempt=1 createdDropletIds=[] lastFailure=SandboxException: Cannot invoke 'dropletserviceserver/DropletCreationStatusImpl.getRequestId()Ljava/lang/String;': the sandboxed connection was invalidated (a prior call 'dropletserviceserver/DropletServiceClientImpl.deleteDroplet(J)V' timed out after 30s). Reopen the connection to use a fresh SJVM sandbox.

This identifies a reported failure chain: a prior deleteDroplet call timed out, the client context was invalidated, and a later getRequestId call could not use that context. It does not establish why the deletion call timed out or which layer should change. No provider fix, service restart, new timeout, or run resubmission was attempted.

Two suite runs were still PENDING with zero executed tests at the last fresh snapshot (2026-10-19 09:01:40 UTC): https://buildtest.kotlin.build/run?id=4fe66580 and https://buildtest.kotlin.build/run?id=871ca9c6 . Their local clients and watchers were stopped. Remote runs were not deleted or resubmitted.

Relevant refs

• Review work: https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/1530 (OPEN, draft, remote head 892e20d2039c3b582e519260a3e43d376f744dee at verification).
• Observed failed run: https://buildtest.kotlin.build/run?id=dda1c35b .
• No source code was changed, published, or deployed for this blocker. No branches were created for it.

Next steps

1. Re-verify current run and provider state first; preserve existing logs before any production action.
2. Trace the deletion call's failure and the subsequent use of the invalidated context. Reproduce the actual failure through the owning public APIs before changing code.
3. Repair the layer that owns the demonstrated defect, with the required tests and review. Deployment needs explicit authorization.
4. Once the provisioning path is demonstrably working, resume the review task's fixed-source and main-source controls and full-suite gate. Do not count pre-execution placeholders as test failures or blindly resubmit failed runs.

Operational notes

The WUI results endpoint returned HTTP 503 while its durable-test-results cache rebuilt. A fresh runs response later reported the terminal provisioning failure. ConnectionClosedEffect logs followed by client reconnects were preserved as observations, not test verdicts.

OBSERVED 2026-10-19 09:09 UTC final live correction: /api/runs?limit=500 returned outOfDate=false. Both suite jobs 4fe66580 and 871ca9c6 are now CANCELED, 0 passed, 0 failed, with exact message Build was cancelled by user: kompile-cli process interrupted. Stopping their clients therefore propagated cancellation to the service. No explicit delete/resubmit action occurred. The earlier PENDING snapshot above is historical, not current. Fixed dda1c35b remains FAILED with 0 passed, 0 failed, 8 total and the same provisioning error. No remote job remains active among these three.