Json on Luther Monson

Proxmox JSON, Part 2: null PIDs, 1.12589990684262e+15 and net10

Tue, 23 Jun 2026 20:31:00 -0700

In 2023 I wrote about why go-proxmox has StringOrInt and friends. Proxmox sends the same number quoted in one place and bare in another, so the client has types that accept both. That post ended on a pretty confident note. Since then three more shapes of “the JSON is valid and Go still won’t take it” have come in. One of them is a bug I’d already fixed once and then reintroduced myself.

Your Zero Value Just Turned Off My TLS Verification: omitempty, Go Defaults and Proxmox

Sat, 13 Jun 2026 19:52:00 -0700

Every Go developer knows omitempty drops zero values. What takes longer to sink in is that a plain bool only has two states. A caller filling in an options struct means one of three:

“set it true”
“set it false”
“I didn’t touch this, do whatever the server does by default”

With omitempty you lose “false”. Without it you lose “didn’t touch it”. In go-proxmox we managed to ship both bugs, in that order. The second one quietly turned off TLS certificate verification for anyone downloading ISOs through the API.

Proxmox Doesn't Know What Type a Number Is

Sat, 25 Nov 2023 20:05:00 -0700

Every couple of months somebody opens an issue on go-proxmox with a title that starts with json: cannot unmarshal string into Go struct field. The most recent one was fixed last week. It’s the same root cause every time. The Proxmox VE API is backed by Perl, and Perl doesn’t really care whether a scalar is a number or a string. The JSON encoder on the other end writes whatever the scalar happens to be at the time. So a field that is documented as an integer comes back as 2048 from one endpoint and "2048" from another. Sometimes it changes on the same endpoint depending on how the value got into the config.