healthcheck reports ready: true on an adminless contract: the readiness signal ignores governance-dead state

[usmanimamu17-create]

Problem

healthcheck (src/lib.rs) decides readiness from the storage version alone:

pub fn healthcheck(env: Env) -> HealthcheckResult {
    let stored_version: Option<u32> = env.storage().instance().get(&STORAGE_VERSION_KEY);
    let (ready, status) = match stored_version {
        None => (false, symbol_short!("noinit")),
        Some(v) if v != STORAGE_VERSION => (false, symbol_short!("migrate")),
        Some(_) => (true, symbol_short!("ok")),
    };
    ...
}

After renounce_admin (which removes ADMIN_KEY and leaves the contract with no admin and no pending admin — the batch 08 companion issue shows the pending-operator hole), the storage version is still current, so healthcheck returns ready: true for a contract whose admin-gated functions are permanently locked.

Consequences:

• Load-balancer probes certify a governance-dead contract: the documented use is "simple load-balancer probes"; a contract that can never be reconfigured, unpaused (pause is admin-gated), or migrated reports ok, so operators get no alert that the contract is in a terminal state.
• The readiness definition is narrower than the word: "ready" implies operational; the check covers only init/version posture, not pause, freeze, or role state — and the docstring doesn't say so.
• The renounce state is unmonitorable: the companion issue documents that adminless contracts are NotInitialized-like on admin reads; the health endpoint is the natural place to surface that state, but it is silent.

Root cause

healthcheck was written to mirror get_version_info's minimal version posture; governance state (admin presence) was never included in the readiness definition.

Why this is architecturally hard

1. Expanding readiness (e.g. ready: false with a new noadmin status when ADMIN_KEY is absent) is a behavior change for probes that currently expect ok for any initialized contract; the status symbol vocabulary must be extended (an additive change to HealthcheckResult's semantics, and the status values should be documented).
2. There is a design question of how many states "ready" should encode: version, pause, freeze, roles — each addition makes the probe more informative but the endpoint's simplicity (its stated virtue) erodes.
3. The get_contract_info needs_migration unreachability companion issue shows the same class of "struct field exists but the guard errors first" — the health and info endpoints should share one documented readiness model.

Acceptance criteria

• An adminless contract does not report ready: true (or the readiness definition is documented to exclude governance state, with a separate signal added).
• The status vocabulary is documented.
• Tests cover healthcheck after renounce_admin.

Out of scope

The renounce pending-operator hole (companion issue in batch 08) and consolidating the readiness/version endpoints (companion issue in batch 03).

Getting started

just test

Good first files to read: apexchainx_calculator/src/lib.rs (healthcheck, renounce_admin), apexchainx_calculator/src/governance.rs.

[TheHalalHunter]

I’d like to work on updating the readiness model for healthcheck. Returning ready: true on an adminless contract hides a terminal governance state from load-balancer probes and monitoring systems.

[madisonsc52-del]

Hi maintainer i can work on this, I'll make sure to work on the issue asap

[Prozaks]

Hi Maintainer,

I'd like to work on this issue. I'm a full-stack developer with experience in JavaScript, Python, TypeScript, and Rust, and a history of contributing to open-source projects.

I've reviewed the scope and can deliver a solid implementation within 24 hours of being assigned. Happy to share past work if helpful.

Thanks for considering me!

[badmusdare4]

@badmusdare4 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Kindly assign this issue to me maintainer.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @badmusdare4 to this issue.

[Brainoncrack]

@Brainoncrack has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, maintainer i would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Brainoncrack to this issue.

[drips-wave]

Congratulations, @Brainoncrack! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Brainoncrack: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊