wire

command
v1.36.181 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Aug 30, 2026 License: BSD-3-Clause Imports: 30 Imported by: 0

Documentation

Overview

wire writes down the ZAP wire of the messages this node's RPC answers with.

A field on that wire IS an offset, and an id is [32]byte — bytes_fixed[32] in the IDL — which the reflective encoder refuses outright. It refuses on purpose: the layout knows the shape, so a schema states an id correctly, and the type is expected to state its own wire rather than quietly acquiring one by reflection. Until it does, a reply carrying an id cannot cross the op-call plane at all, and most of what a P-Chain or X-Chain call answers with carries one.

Two passes, because the two halves know different things.

go run ./cmd/wire -scan     reads the SOURCE for every handler and writes
                            messages.go, the list of what those handlers
                            take and return
go run ./cmd/wire           reads those TYPES and writes each package's
                            zap_gen.go from [zip.LayoutOf]

The second pass reads the types by importing them, so the module has to compile for it to run. Across a zip upgrade that changes what is emitted, the files on disk are the thing stopping it: delete them first.

find . -name zap_gen.go -delete && go run ./cmd/wire

Neither pass derives a layout of its own. The offsets a codec states are the ones the plane encodes against, which is what lets a codec go out one node at a time: the node that has it and the node that has not are speaking one wire.

A message the derivation refuses is REPORTED, never guessed at. Those are the ones whose Go type has no layout to state — a map, an interface, a fixed array of anything but bytes — and the answer is to change the type, which is not something a generator gets to do.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL