[Leechael]

Problem

Clicking Onboard or Bootstrap again after keys have been stored returns KMS has already been onboarded (or bootstrapped). The page previously treated this as failure and hid Finish Setup. Reloading also lost the public keys from the first response, with no way to query the stored setup state.

Fix

• Add Onboard.GetSetupStatus to read the stored public key and report whether root keys and all required certificates are present. ready implies provisioned. Bootstrap display material is optional: missing, malformed, or mismatching bootstrap_info does not prevent setup recovery.
• Keep Onboard and Bootstrap rejecting attempts to provision existing root keys; auto-bootstrap also refuses to replace them.
• Restore completed setup on page load. If a provisioning request fails on the client after succeeding server-side, re-query setup status to recover without a reload.
• Disable setup controls only while the setup-status query or a setup action is pending, independently of the attestation-info request. Hide provisioning forms after success or when stored root keys lack required certificates.
• Share result rendering across initial recovery, Bootstrap, and Onboard. Keep Finish Setup visible when /finish fails.

Verification

• cargo test --manifest-path dstack/Cargo.toml -p dstack-kms --all-features: 60 passed, including 3 setup_status_* tests covering unprovisioned, matching, and absent/invalid bootstrap information.
• Node.js VM checks of the onboard page script: 10 passed, covering independent attestation loading, recovery after lost Bootstrap/Onboard responses, original-error preservation, restored results, incomplete setup, and Finish retry.
• cargo clippy --manifest-path dstack/Cargo.toml -p dstack-kms --all-features -- -D warnings -D clippy::expect_used -D clippy::unwrap_used --allow unused_variables passed.
• prek run --files dstack/kms/src/onboard_service.rs dstack/kms/src/www/onboard.html dstack/kms/rpc/proto/kms_rpc.proto passed.

[kvinwang]

Thanks, the GetSetupStatus approach looks right, and keeping Finish visible after a /finish error is a good fix.

The PR description is out of date. It says Onboard/Bootstrap return the stored keys instead of erroring and that the UI treats the already-provisioned error as success, but the final code still bails in both RPCs and adds a new Onboard.GetSetupStatus RPC instead. The Verification section lists stored_ and auto_bootstrap_ tests rather than the new setup_status_* ones. Please update it to describe the final approach.

The other comments are inline: one functional gap (recovering without a reload when the request succeeds server-side but fails on the client), one UX regression (the buttons now wait on GetAttestationInfo), and several simplifications.

[kvinwang]

Five tests for a small status reader feel like a lot. After the simplification above, covering not-provisioned, matching bootstrap info and mismatching bootstrap info should be enough.

[kvinwang]

Changing the existing rule to button:not(:disabled):hover makes this override unnecessary.