fix(dapi): truthful state sync status, health height field collision, client crash on absent sections

[PastaPastaPasta]

Issue being fixed or feature implemented

Three status-reporting bugs found during state-sync QA (all observed live on a state-synced local node). Independent of the state-sync feature PRs — these affect today's v4.2-dev.

What was done?

• rs-dapi: stop emitting misleading all-zero stateSync counters. Tenderdash 1.7 never populates the six state-sync counters in /status — env.StateSyncMetricer has no assignment site anywhere in tenderdash (the reactor is dropped into node.services with no reference kept, and *statesync.Reactor doesn't even implement the Metricer interface), so the fields are always "0". rs-dapi's emit gate was additionally inverted (json:",string" means the fields are never absent, so the "is any data present" check always passed). getStatus now emits the stateSync section only when one of the six state-sync-specific counters is non-zero — absent rather than "state sync ran and did nothing" — and block-sync progress fields no longer leak into the state-sync section. The precise tenderdash-side fix (wire the reactor into rpcEnv, implement the two missing Metricer methods, snapshot syncer values before syncComplete() nils them, persist across restart) is documented in the code and being addressed separately.
• rs-dapi: /health no longer reports a Core height under the name latestBlockHeight. getStatus's chain.latestBlockHeight was always correct (tenderdash platform height); the collision was checks.coreRpc.latestBlockHeight on the unversioned /health endpoint, sourced from Core getblockcount — the exact number QA observed. Renamed to coreBlockHeight (no in-repo consumers of the old key), with a regression test pinning that chain.latest_block_height is the platform height.
• js-dapi-client: getStatus no longer throws on nodes missing optional sections. getStateSync(), getNode(), getChain(), getNetwork(), getTime(), and the nested version getters were all called unguarded; any of them absent (never-synced node, Drive or tenderdash unreachable) threw a TypeError. All optional sub-messages are now guarded, with unit tests for the absent-section shapes.

How Has This Been Tested?

rs-dapi: 307 unit tests passing including 7 new/changed (mid-sync, post-sync, never-synced, block-sync-only fixtures; height-collision regression). js-dapi-client: 320 passing including new absent-section cases. fmt/clippy clean. code-review-validator gate run; both valid findings fixed.

Breaking Changes

/health's checks.coreRpc.latestBlockHeight key is renamed to coreBlockHeight (unversioned diagnostics endpoint; no in-repo consumers — external scrapers of that exact key would need the one-word update). getStatus omits the stateSync section when there is no state-sync data instead of emitting zeros.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation if needed

---

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Final review complete — no blockers (commit bdff957)

[thepastaclaw]

Final validation — Sol-only technical fallback

The status builder now omits stateSync unless state-sync-specific counters justify the section, while preserving the existing timing payload when genuine state-sync data is available. The proposed blocker conflates presence gating with payload preservation; the implementation, regression tests, and existing protobuf schema make that distinction explicit, so no actionable findings remain.

Source: reviewer 1: gpt-5.6-sol (agent: sol-fallback-reviewer, role: general); reviewer 2: gpt-5.6-sol (agent: sol-fallback-reviewer, role: rust-quality); final verifier: gpt-5.6-sol (agent: sol-verifier, role: final-verifier)

One or more required Phase-1 GLM Flash lanes remained technically unusable after the bounded exact-model retry. Their evidence was discarded as authoritative, and the complete selected role cohort was rerun fresh on exact gpt-5.6-sol before this fresh Sol verifier produced the final decision. No additional Phase-2 reviewer pass ran.

Review provenance

• Phase 1 GLM evidence: technically unusable after bounded retry; discarded from the decision
• GLM failure attempts: codex-general-259753a23f144b6392bd0f78eb193856 (failed), codex-general-55495ae61dd540818d15ac60e0dd5ff6 (failed), codex-rust-quality-478f1aae62394461b64986f1f9b6a58a (failed), codex-rust-quality-8d92ce1cc5b94fdebcf6375637ba6a5f (failed)
• Sol-only fallback reasons: launch_transport_or_nonzero_exit, launch_transport_or_nonzero_exit
• Sol-only fallback reviewers: gpt-5.6-sol — general (completed); agent sol-fallback-reviewer, gpt-5.6-sol — rust-quality (completed); agent sol-fallback-reviewer
• Fresh verifier (Sol): gpt-5.6-sol — final-verifier; agent sol-verifier
• Additional Phase 2 pass: not run; the Sol-only fallback is final