fix(server): encode typed slices/maps in resource status/spec over the wire#119
Merged
Conversation
…e wire Browsing a ProxmoxNode 500'd with `encode: status: proto: invalid type: []string`. The node Get enriches status with storages/bridges as []string (internal consumers + the dependent-dropdown resolution expect that type), but normalizeValue — which prepares spec/status for structpb.NewStruct — only recursed into []any, so a typed slice fell through unchanged and structpb rejected it. Fix normalizeValue at the wire boundary (not the source, to preserve the internal []string contract): a reflection fallback converts any typed slice/array/map to the generic []any / map[string]any structpb accepts, recursing through elements. []byte still passes through (structpb encodes it as base64). This hardens every provider's status/spec — including external plugins — not just this one field. Added TestResourceToProtoEncodesTypedContainers covering []string, []int, map[string]string, a typed slice nested in []any, and []byte.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
Browsing a ProxmoxNode in the UI returned:
Cause
ProxmoxNode's single-node Get enrichesstatus.storages/status.bridgesas[]string(internal consumers and the dependent-dropdown resolution expect that concrete type). When the server encodes status into agoogle.protobuf.Struct,normalizeValue(resource.go) only recursed into[]any— a typed slice like[]stringfell throughdefaultunchanged, andstructpb.NewStructrejects it withinvalid type: []string. Every resource-encode path (GET, list, watch) routes through this, so the node was unviewable.Fix
Harden the wire-normalization boundary rather than the source (keeping the internal
[]stringcontract that tests + dropdown resolution rely on).normalizeValue's fallback now uses reflection to convert any typed slice/array/map to the generic[]any/map[string]anythat structpb accepts, recursing through elements.[]bytestill passes through (structpb encodes it as base64). This fixes the class of bug for any provider's status/spec, including external plugins — not just this one field.Test
TestResourceToProtoEncodesTypedContainersdrives the realresourceToProtopath with[]string(the exact trigger),[]int,map[string]string, a typed slice nested inside[]any, and[]byte, asserting correct structpb values.Local CI
gofmt / go vet / staticcheck / golangci-lint / modernize (generated-filtered) /
go test(server + proxmox) /go test -race(server) all green.Note: the encode bug is server-side and fully covered by the unit test; end-to-end reproduction against live Proxmox is currently gated by an unrelated macOS Local Network Privacy block on the dev machine.