/nodes: Type badge decided by fuzzy name-match, not the node's voting_power — node1 shown as Sync while bonded

Aperta
  • Qualcosa non va?
#588 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@efegokdemir ci sta già lavorando.

Dal 21/9/2026.

  • #649 di @efegokdemir — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
82/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
blockchain, frontend

Direzione di ricerca

Start in src/pages/NodesPage.tsx, especially checkNode(), the isValidator() helper, and the existing NodesPage tests. Trace how node status and the validator and sync counts are rendered, then verify the RPC status response and update the tests. Done means unrelated preset and staking moniker names no longer affect the badge, and the listed rows and tiles show the accepted counts.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug cosmos

Symptom

/nodes shows Block52 (node1.block52.xyz) as Sync and only Miller Services as Validator, while the tile above the table says 2 Validators. Seen 2 Sep 2026 at height ~2,700 on the fresh USDC-only chain (block52/pokerchain#321).

On-chain truth (each node's own /rpc/status):

Preset Endpoint validator_info.voting_power Staking moniker /nodes shows
Block52 node1.block52.xyz 10 node1 Sync ❌
Texas Hodl node.texashodl.net 0 not bonded Sync ✅
Miller Services node.tommillerservices.com 10 millerservices Validator ✅

Root cause — src/pages/NodesPage.tsx isValidator()

The Type badge is not read from the chain. isValidator(network.name) fuzzy-matches the preset display name (lowercase, strip spaces/dashes/underscores, substring either way, strip "validator") against the bonded validators' staking monikers from getValidatorsByStatus("BOND_STATUS_BONDED"):

  • "Miller Services" → millerservices ⊇ moniker millerservices → Validator ✓
  • "Block52" → block52 vs moniker node1 → no overlap → Sync ✗

The 2 Validators tile is right because it uses validators.length straight from the staking API — hence tile and table disagree. Same code path drives presetValidatorCount / totalSyncNodes, so the Sync Nodes count is off by one too (shows 3, should be 2).

Fix

checkNode() already hits each node's REST for the latest block. Add a call to the node's RPC status and take the type from the node itself:

// in checkNode(network)
const st = await fetch(`${network.rpc}status`, { signal: AbortSignal.timeout(5000) }).then(r => r.json());
const votingPower = Number(st?.result?.validator_info?.voting_power ?? 0);
return { status: "online", blockHeight: header?.height ?? null, isValidator: votingPower > 0 };

Then render the badge / counts from node.isValidator and delete the moniker-matching isValidator() helper. (Alternative that keeps the helper: compare validator_info.address against /rpc/validators — still key-based, never name-based.)

Not a fix: renaming node1's moniker to block52 would make today's match pass but leaves the next validator with a mismatched name in the same hole.

Acceptance

  • Block52 row shows Validator; Texas Hodl shows Sync; Miller Services shows Validator.
  • Tiles: 2 Validators, 2 Sync Nodes (with the Stub offline preset counted as it is today).
  • A node whose preset name shares nothing with its staking moniker is still labelled correctly.
  • Existing NodesPage tests updated; add one case for "voting_power 10 + unrelated preset name → Validator".

Context: block52/pokerchain#321 (millerservices bonded 2 Sep 2026).

Lingua principale
TypeScript
Stelle
2
Fork
5
Merge medio
22h 35m
PR unite (30g)
91

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di block52/ui

Tutte le issue di block52/ui

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.