[bug] OverridePathInMap panics with "index out of range" when an override path indexes an array out of bounds

[Abhishek9639]

Describe the bug

framework.OverridePathInMap panics instead of returning an error when a dotted override path indexes into an array with a bad index and the path continues past that index.

The bounds checks in overridePathInArray only exist in the len(path) == 1 branch. When there are more path elements after the array index, it falls through to the type switch at framework/override_utils.go:148, which does output[pathIndex] with no check. Anything out of range panics. Negative indexes too, so -1 (which means "append" in the terminal case) also panics when something comes after it in the path.

This is reachable from user input. score-compose, score-k8s, score-helm and score-radius all pass --override-property values straight into this function, so a typo'd index crashes the CLI with a Go stack trace instead of the usual --override-property '...' could not be applied: ... message.

To Reproduce

At the library level, against main:

input := map[string]interface{}{
	"volumes": []interface{}{
		map[string]interface{}{"source": "a"},
	},
}

// index 3 is out of range and the path continues after it
_, _ = framework.OverridePathInMap(input, framework.ParseDotPathParts("volumes.3.source"), false, "x")
// panic: runtime error: index out of range [3] with length 1

// -1 followed by a nested path
_, _ = framework.OverridePathInMap(input, framework.ParseDotPathParts("volumes.-1.source"), false, "x")
// panic: runtime error: index out of range [-1]

Or end to end with score-compose 0.41.0 (pins score-go v1.18.0), using any workload that has one volume:

$ score-compose generate score.yaml --override-property 'containers.main.volumes.3.source="foo"'
INFO: Overriding 'containers.main.volumes.3.source' in workload
panic: runtime error: index out of range [3] with length 1

goroutine 1 [running]:
github.com/score-spec/score-go/framework.overridePathInArray(...)
        .../score-go@v1.18.0/framework/override_utils.go:148 +0x850
github.com/score-spec/score-go/framework.overridePathInMap(...)
        .../score-go@v1.18.0/framework/override_utils.go:108 +0x30c
github.com/score-spec/score-compose/internal/command.parseAndApplyOverrideProperty(...)
        .../internal/command/generate.go:523

The terminal versions of the same paths behave correctly: volumes.3 returns cannot set '3' in array: out of range and volumes.-1 appends. Only the nested case is unchecked.

Expected behavior

An error return, same as the terminal branch gives: cannot set '3' in array: out of range. The CLIs already wrap errors from this function in a friendly message; the panic bypasses all of that.

Screenshots

n/a, terminal output above.

Desktop (please complete the following information):

• OS: macOS (arm64), though nothing here is platform specific
• Version: score-go v1.18.0 and current main (f894f40), observed through score-compose 0.41.0

Additional context

The fix looks small: a bounds check in overridePathInArray before the type switch, mirroring the error the terminal branch already produces.

if pathIndex < 0 || pathIndex >= len(output) {
	return nil, fmt.Errorf("cannot set '%d' in array: out of range", pathIndex)
}
switch typed := output[pathIndex].(type) {

-1 with a nested path could arguably mean "append a new object and keep going", but returning an error seems safer and keeps the behavior consistent. Happy to open a PR with the fix plus regression tests for both cases.

[Abhishek9639]

flagging this one for your eyes since it's in the framework package you maintain.

I've reproduced it on current main and end-to-end through score-compose 0.41.0, and the fix looks like a small bounds check in overridePathInArray. Happy to open a PR with the fix + regression tests if you agree with the approach open to any feedback on how you'd prefer it handled (error vs. defining -1 as append for nested paths).

[Siddhartha-singh01]

Hi @Abhishek9639, thanks for the detailed write-up and repro steps this is a really well-documented bug report!

I'm currently an active contributor to the framework package (working on the #191 network types lift PR #200 is open) so I'm already familiar with this area of the codebase. I'd like to pick this one up.

My understanding of the bug:

The overridePathInArray function in framework/override_utils.go only validates the array index bounds in the terminal case (len(path) == 1), where it correctly returns a cannot set '%d' in array: out of range error. However, when the path continues past the array index (i.e., a nested path like volumes.3.source), it skips the bounds check entirely and goes straight to output[pathIndex] at line 148, which causes a Go runtime panic instead of a graceful error.

The same issue applies to negative indexes -1 in the terminal case means "append", but in the nested case it panics with index out of range [-1].

My proposed fix:

Add a bounds check in overridePathInArray before the type switch, so that both terminal and nested paths are validated consistently:

This mirrors the error message from the terminal branch and ensures the CLIs (which already wrap errors from this function) can display a friendly message instead of crashing with a stack trace.

I'll also add regression tests covering:

Out-of-range positive index with a nested path (e.g., volumes.3.source)

Negative index with a nested path (e.g., volumes.-1.source)

Ensuring existing terminal-case behavior remains unchanged

I've already started working on this and will open the PR as soon as possible.

Thanks !

[Abhishek9639]

Hi @Siddhartha-singh01,
This approach looks perfect. You can go ahead and work on it since I'm currently busy with some other tasks. Once you open the PR, I'll review your code, and if I feel any changes are needed or notice anything that should be improved, I'll definitely let you know.

[Abhishek9639]

@mathieu-benoit mind taking a quick look and confirming this is worth fixing? @Siddhartha-singh01 let's wait for their confirmation before you pick it up.
Thanks!