fix(parameters): return an error instead of panicking on a non-string type field

[he-yufeng]

Description

parseParamFromDelayedUnmarshaler reads the type field from a parameter map and passes it straight to ParseParameter with an unchecked type assertion:

return ParseParameter(ctx, p, t.(string))

If a tools file declares a parameter whose type is not a string (for example type: 123 from a YAML typo, or type: left as a mapping), t.(string) panics with interface conversion: interface {} is int, not string instead of surfacing a config error. The panic propagates out of UnmarshalYAML, so a single malformed parameter takes down config loading with a stack trace rather than a readable message.

This is inconsistent with the rest of the function and with ParseParameter itself: the missing-type case right above already returns a clean error, and ParseParameter's switch has a default branch that reports unknown types as errors. Only the string assertion was unguarded.

The fix uses the comma-ok form and returns the same style of error the surrounding code already uses:

typeStr, ok := t.(string)
if !ok {
    return nil, fmt.Errorf("parameter 'type' field must be a string, got %T", t)
}
return ParseParameter(ctx, p, typeStr)

Added a TestFailParametersUnmarshal case ("common parameter with non-string type") that feeds an integer type and expects the error. I confirmed it panics on main before the change and passes after; the full internal/util/parameters package still passes and gofmt/go vet are clean.

Note this is a separate concern from #3512, which also touches parameters.go but in a different function (the array/map element parsing paths). No overlap with that change.

PR Checklist

• Make sure you reviewed CONTRIBUTING.md
• Ensure the tests and linter pass
• Code coverage does not decrease (added a test covering the new branch)
• Appropriate docs were updated (no behavior/doc change, internal robustness fix)

[gemini-code-assist]

Code Review

This pull request improves the robustness of parameter parsing in internal/util/parameters/parameters.go by safely asserting that the type field is a string, preventing potential panics when a non-string type is provided. A corresponding unit test has been added to verify this behavior. There are no review comments, and I have no additional feedback to provide.

[Yuan325]

Hi @he-yufeng , thank you for your contributions

[Yuan325]

/gcbrun

[Yuan325]

/gcbrun