Files
explore/lib/socket
zeekay 2e1012b761 fix(home): map the realtime block onto the API shape before it reaches the list
The home page rendered the error boundary — "Oops! Something went wrong" —
within seconds of loading, on every explorer in the estate, with no interaction
at all:

  TypeError: Cannot read properties of undefined (reading 'length')
      at HashStringShorten (ui/shared/HashStringShorten.tsx:17)

The list on the home page is filled from the REST API and then kept current by
the realtime stream, and the two do not agree on what a block looks like.
/main-page/blocks answers with the API shape — `height`, and `miner` as an
address object. The indexer broadcasts a raw EVM block:

  data: {"event":"blocks","chain":"cchain","data":{
    "number":1090152,"miner":"0x0100...","txCount":4, ... }}

`new_block` put that straight into the same query cache, so LatestBlocksItem
handed `AddressEntity` a bare string. `address.hash` on a string is undefined,
the entity passed undefined down as its text, and HashStringShorten read
`.length` off it. Instrumented in a dev build: the four blocks that arrive over
the stream log `miner` as a string with no `height`, against six from REST that
carry both — and exactly four entities then render with no text.

TRANSLATIONS already exists as the one place a backend broadcast becomes app
data, and it already has a transform hook, so the shape is settled there rather
than at each reader. Everything downstream keeps knowing exactly one block
shape, which is what it already assumed.

The spec asserted the raw passthrough, so it encoded the bug; it now asserts
the mapped shape and covers `miner` specifically.
2026-08-06 12:20:11 -07:00
..
2022-11-08 10:35:17 +03:00