[paoValle]

What type of PR is this?

• bug

What this PR does / why we need it:

A slice flag splits its value on commas, and mapValueSource.Lookup formatted whatever it found with %+v. A list in the map therefore reached the flag as "[80 443]": the IntSliceFlag from the issue fails to parse it, and a StringSliceFlag keeps the whole string as one element without reporting an error.

A comma-joined value would fix the reported case and break the next ones: an element that contains a comma is silently split, and SliceFlagSeparator/DisableSliceFlagSeparator change the separator the flag expects. So Lookup returns slices and arrays in the serialized form SliceBase.Set already parses, which bypasses splitting entirely. Scalars format as before.

Which issue(s) this PR fixes:

Fixes #2516

Tests

TestMapValueSourceFeedsSliceFlags drives a command with an IntSliceFlag and a StringSliceFlag fed from a map source, which is the reproduction in the issue, and checks the parsed values. TestMapValueSourceListSeparators covers an element containing a comma, a command with SliceFlagSeparator: ";" and one with the separator disabled. Reverting the Lookup change fails them with the error from the issue.

Release Notes

A list in a map value source now reaches a slice flag intact, instead of failing on `"[80 443]"` or silently keeping one element.

[yxshee]

I opened #2516, so I ran this against a few more config shapes. Keeping commas inside elements and honoring a custom or disabled separator is a real improvement over just joining the items with commas. The catch is that the serialized path skips the per-element parsing, and SliceBase.Set drops the json.Unmarshal error, so when the JSON types don't match the flag's element type the flag ends up with zero values and no error:

map value	flag	this PR	joining with ,
[]any{80, 443}	StringSliceFlag	["" ""]	["80" "443"]
[]string{"80", "443"}	IntSliceFlag	[0 0]	[80 443]
[]any{"a", 2, true}	StringSliceFlag	["a" "" ""]	["a" "2" "true"]
[]any{-1}	UintSliceFlag	[0]	parse error
[]string{"x", "y"}	StringFlag	sl:::1793718754028232588:::["x","y"]	x,y

cmd.Run returned nil for all of these on this branch. The first row is probably the common one, since YAML like ports: [80, 443] decodes to []any of ints, and a string slice is a reasonable flag for it. The last row is the internal prefix leaking into a non-slice flag.

A couple of ways to keep the separator fix without this: in the serialized branch, unmarshal into []string (formatting each element with %+v on the value source side) and pass each item through the flag's value parser, the same way the split path does. At a minimum, returning the json.Unmarshal error there would turn the silent zeros into an error.

The tests in the PR pass for me, as do go test ./..., gofmt and go vet.

[paoValle]

Both shapes are fixed in e0a31644. The serialized branch now decodes the array and hands each element to the same parser the split path uses, so the first four rows behave like your joining column: []any{80,443} into a StringSliceFlag gives ["80" "443"], []string{"80","443"} into an IntSliceFlag gives [80 443], the mixed row gives ["a" "2" "true"], and []any{-1} into a UintSliceFlag returns a parse error instead of [0]. The last row is handled before Set: a scalar flag gets the elements comma-joined (x,y), never the sl::: prefix. TestMapValueSourceListsWithMismatchedTypes pins all five, and the suite and vet are green.

[paoValle]

Replaced e0a31644 with 91614ffc: same behaviour, but the serialized array is now scanned instead of decoded.

Decoding into any concrete type ([]string, []any, []json.RawMessage) links the whole encoding/json decoder here, which took the example binary from 2.0 MB to 2.4 MB and failed the binary-size check. A serialized slice is a flat array of scalars, so the scan only finds the element boundaries; TestMapValueSourceListElementsSurviveTheSerializedForm pins commas, quotes, backslashes, newlines, empty strings and brackets.

The five rows behave as described above, everything is green, and the binary is back at its 2.0 MB.

[paoValle]

The branch head is 458cde65 now: it adds tests for the scanner's refusals (malformed array, unterminated string, bad escape, nested value, missing comma), which is what the patch-coverage check was flagging, plus a check that a malformed value reaches the caller as an error.