deploy_vm returns Ok before the spawned substrate submission finishes #120

New issue

Closed

opened 2026-05-23 16:04:22 +00:00 by mik-tf · 1 comment

mik-tf commented

2026-05-23 16:04:22 +00:00

Owner

ComputeService.deploy_vm (at crates/my_compute_zos_server/src/cloud/rpc.rs:1116-1213) returns a successful response carrying a vm_sid as soon as the local slice allocation completes, but the substrate createDeploymentContract calls run in a tokio::spawn'd task that the RPC handler does not await. Callers persist their local state (vm_secret, vm_sid, owner mapping) based on the synchronous Ok return, before the on-chain write has actually landed. If the caller crashes or the network drops between the daemon's Ok response and the caller's own state-write, the spawned task can still create one or two on-chain contracts that the caller no longer has a reference to, costing TFT indefinitely. This is the symmetric twin of issue #119 (delete_vm). Fix: await the spawned submission task and return Ok only after substrate ack lands, or expose an explicit pending state the caller can poll. See cloud/rpc.rs:1116-1213 and the spawned task block at line 1116.

`ComputeService.deploy_vm` (at `crates/my_compute_zos_server/src/cloud/rpc.rs:1116-1213`) returns a successful response carrying a `vm_sid` as soon as the local slice allocation completes, but the substrate `createDeploymentContract` calls run in a `tokio::spawn`'d task that the RPC handler does not await. Callers persist their local state (vm_secret, vm_sid, owner mapping) based on the synchronous Ok return, before the on-chain write has actually landed. If the caller crashes or the network drops between the daemon's Ok response and the caller's own state-write, the spawned task can still create one or two on-chain contracts that the caller no longer has a reference to, costing TFT indefinitely. This is the symmetric twin of issue #119 (delete_vm). Fix: await the spawned submission task and return Ok only after substrate ack lands, or expose an explicit pending state the caller can poll. See `cloud/rpc.rs:1116-1213` and the spawned task block at line 1116.

mik-tf referenced this issue from a commit

2026-05-24 05:12:11 +00:00

zos: await substrate ack inline on deploy_vm + delete_vm (D-27, #119, #120)

mik-tf closed this issue

2026-05-24 05:12:11 +00:00

mik-tf commented

2026-05-24 16:58:16 +00:00

Author

Owner

Cross-referencing the s156 walk evidence detailed at #119 — the D-27 substrate-await fix at 39d9b8a is incomplete on the error path for both deploy_vm and (by symmetry) delete_vm. The same rollback-on-error pattern that #119 needs on the deploy side is needed on the delete side too: if delete_vm errors after publishing a cancel intent to substrate, the on-chain state may end up half-cancelled with no client-side record. Tracking both fixes together since the structure is identical.

Signed-by: mik-tf mik-tf@noreply.invalid

Cross-referencing the s156 walk evidence detailed at https://forge.ourworld.tf/lhumina_code/hero_compute/issues/119 — the D-27 substrate-await fix at 39d9b8a is incomplete on the error path for both deploy_vm and (by symmetry) delete_vm. The same rollback-on-error pattern that #119 needs on the deploy side is needed on the delete side too: if delete_vm errors after publishing a cancel intent to substrate, the on-chain state may end up half-cancelled with no client-side record. Tracking both fixes together since the structure is identical. Signed-by: mik-tf <mik-tf@noreply.invalid>

mik-tf referenced this issue from a commit

2026-05-24 19:41:03 +00:00

fix(cloud/rpc): resolve node by sid not hostname + classify deploy failures

mik-tf referenced this issue

2026-05-25 15:00:49 +00:00

deploy_webgateway returns Ok before substrate ack — D-27 incomplete (same race #119/#120 fixed for deploy_vm/delete_vm) #126

mik-tf referenced this issue from a commit

2026-05-25 15:01:43 +00:00

hero_compute: extend D-27 inline-await to deploy_webgateway