Summary
We are seeing a confusing ROFL operational state on testnet:
oasis rofl show --format json reports active replicas- the configured machine pointer still resolves to a machine that shows
accepted (EXPIRED)
oasis rofl machine logs --yes for that machine returns 404 Not Foundoasis rofl deploy --replace-machine --yes does not give us a reliable operator-visible signal that a fresh machine was actually rented and started
This makes it hard to tell whether a new rollout really happened, and it blocks strict-mode validation of our ROFL app.
Environment
- Oasis testnet
- ROFL app using managed provider flow
- CLI version in active use on 2026-04-12
Observed behavior
oasis rofl show --format json shows active replicas.oasis rofl machine show for the configured machine ID shows accepted but also expired state.oasis rofl machine logs --yes returns 404 Not Found.oasis rofl deploy --replace-machine --yes completes, but from the operator point of view we still cannot confidently observe a fresh machine start.
Expected behavior
One of the following should happen clearly:
- a fresh machine ID is created and surfaced to the operator, with logs available, or
- the CLI should fail closed and state that replace-machine did not converge to a fresh runnable machine
Why this matters
From the application side, we can see that active replicas exist, but we cannot correlate them to a fresh rollout with accessible logs. That makes rollout validation ambiguous and turns debugging into guesswork.
Related issues
Additional context
This is not the same as the previously diagnosed evm.SimulateCall / secure query limitation. We already worked around that at the application layer. The remaining blocker is specifically machine lifecycle / rollout observability.
Summary
We are seeing a confusing ROFL operational state on testnet:
oasis rofl show --format jsonreports active replicasaccepted (EXPIRED)oasis rofl machine logs --yesfor that machine returns404 Not Foundoasis rofl deploy --replace-machine --yesdoes not give us a reliable operator-visible signal that a fresh machine was actually rented and startedThis makes it hard to tell whether a new rollout really happened, and it blocks strict-mode validation of our ROFL app.
Environment
Observed behavior
oasis rofl show --format jsonshows active replicas.oasis rofl machine showfor the configured machine ID showsacceptedbut also expired state.oasis rofl machine logs --yesreturns404 Not Found.oasis rofl deploy --replace-machine --yescompletes, but from the operator point of view we still cannot confidently observe a fresh machine start.Expected behavior
One of the following should happen clearly:
Why this matters
From the application side, we can see that active replicas exist, but we cannot correlate them to a fresh rollout with accessible logs. That makes rollout validation ambiguous and turns debugging into guesswork.
Related issues
rofl deployfigure out what to do when the machine expires #487Additional context
This is not the same as the previously diagnosed
evm.SimulateCall/ secure query limitation. We already worked around that at the application layer. The remaining blocker is specifically machine lifecycle / rollout observability.