5 Commits
Author SHA1 Message Date
zeekay 2210675e6e The info, admin and health replies cross the plane carrying their values
A ZAP field is an offset. Eight of these replies held a map, which has no
order to give one, so the reply could not cross between two processes at
all. Two more held values whose fields are every one unexported —
netip.AddrPort, time.Time — and those are worse: they are not refused, they
derive an EMPTY layout, so the reply crossed, reported no error and carried
nothing. GetNodeIPReply has one field, so its whole answer was blank. And a
health check says what it likes, so its details were an `any`, which has no
shape until it holds something.

Each map is now a list of a stated element type, ordered by the key it was
an object of. An address is the text netip already wrote for it, an instant
is three numbers, and a check details are the bytes of their own JSON —
the one shape an object, a string and a list all share.

The JSON does not move. Every list marshals to the object it replaced and
reads one back, and wire_test.go holds that against the old shape spelled
out as a literal rather than against itself. The order is new where there
was none: a map answered the same question two ways.

APIReply also states the status it carries, so the 503 a probe reads and
the healthy a person reads are one fact computed once.
2026-08-29 22:53:03 -07:00
zeekay 1de772ad2d The shapes every chain answers in state their own ZAP wire
A JSONTxID, a GetTxArgs, a GetBlockArgs and the ids inside them are what
P and X reply with, and each holds an ids.ID — [32]byte, bytes_fixed[32]
on the wire, which the derived codec refuses to carry. So none of those
calls could cross the op-call plane. zap_gen.go is generated by
zip.Codecs from the same layout the plane encodes against, and the JSON
edge does not move: encoding/json reads the tags and knows nothing about
a ZAP codec.
2026-08-29 18:58:36 -07:00
zeekay 9098761124 The numerics state the shape they marshal into
Each of these writes itself as a quoted decimal — a JSON number is a float64, so
a uint64 above 2^53 does not survive one — which means a schema built from the
Go fields would describe the integer and not the wire. zip published `{}` for
every one of them: true, since the fields are not the wire form, and useless to
anything generating a client, which then types the field as an untyped value.

The shape is declared beside MarshalJSON because the bytes and the schema are
the same fact about the same type. zip reads it through SchemaDescriber.

This is the JSON EDGE only. On the ZAP plane a u64 is a u64 and none of this
applies — the quoting exists because browsers speak JSON, and it stops at the
boundary where they do.
2026-08-29 13:38:46 -07:00
zeekay 084841011e feat(types): the JSON-RPC boundary carries 16- and 256-bit numbers too
The set was Uint32, Uint64, Float64. Two widths the chain actually uses were
missing, so callers reached past this package for both.

Uint16 is what platformvm's API already asks for today.

Uint256 is the width the EVM carries. A wei value, a token balance or a
supply does not fit in 64 bits — an 18-decimal balance passes 2^64 at about
18.4 tokens — so every such field arriving here had to become a bare string
or a hand-rolled big.Int. It is uint256.Int rather than big.Int because a
fixed-size value cannot be nil and does not allocate; the module was already
in the graph.

Every numeric here is a QUOTED decimal, which is the point of the package: a
JSON number is a float64, and a uint64 above 2^53 does not survive one. The
test asserts Uint64 REFUSES a value it cannot hold, which is the failure
Uint256 exists to prevent.

Unquoting was written out once per type and is now read in one place. Adding
two more types would have made five copies of it.
2026-08-28 21:22:30 -07:00
zeekay b1db41a415 api: initial v1.0.0 2026-01-16 11:52:14 -08:00