ROFL deploy/replace-machine can leave active replicas running while configured machine pointer stays accepted (EXPIRED) and machine logs return 404

まず、関連する issue #487、#580、#584 をコンテキストとして使用し、oasis rofl show --format json、machine show、machine logs --yes、deploy --replace-machine --yes で managed-provider フローを再現します。置換によってマシン ID と準備完了状態がどのように報告されるかを追跡します。新しく実行可能なマシンがアクセス可能なログとともに提示されるか、置換が収束しない場合に CLI が明確に安全側へ失敗すれば完了です。

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 Found
• oasis 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

1. oasis rofl show --format json shows active replicas.
2. oasis rofl machine show for the configured machine ID shows accepted but also expired state.
3. oasis rofl machine logs --yes returns 404 Not Found.
4. 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

• oasisprotocol/cli#487
• oasisprotocol/cli#580
• oasisprotocol/cli#584

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.