Skip to content

Backport(v1.19): Config: accept a bare scalar for an array option in YAML syntax (#5413) - #5433

Merged
Watson1978 merged 1 commit into
v1.19from
backport-to-v1.19/pr5413
Jul 13, 2026
Merged

Backport(v1.19): Config: accept a bare scalar for an array option in YAML syntax (#5413)#5433
Watson1978 merged 1 commit into
v1.19from
backport-to-v1.19/pr5413

Conversation

@github-actions

@github-actions github-actions Bot commented Jul 13, 2026

Copy link
Copy Markdown

Which issue(s) this PR fixes:
Backport #5413
Fixes #5149

What this PR does / why we need it:
In YAML config syntax, a single scalar value for an array option is rejected. For example retryable_response_codes: 503 fails with array required but got 503, while the classic syntax retryable_response_codes 503 works fine. The difference is that the classic path delivers the value as the String "503", which Config.array_value already splits into ["503"], whereas YAML hands it over as a bare Integer that falls straight through to the "array required" check.

This wraps a non-String, non-Array, non-Hash scalar into a one-element array so both config syntaxes behave the same way. The wrapped value then flows through the existing value_type coercion, so retryable_response_codes: 503 becomes [503] just like retryable_response_codes: [503] does. A Hash still raises as before, so an accidental mapping under an array option is not silently accepted.

I could not run the full suite locally (my Ruby is 2.6 and Fluentd needs 3.2), so I verified the logic by tracing the exact array_value path and reproducing it in isolation; CI should confirm. I added test cases in test/config/test_types.rb covering a bare integer with and without value_type, and that an existing array is left untouched.

Docs Changes:
None.

Release Note:
Fix a config error when a single scalar value is given to an array option in YAML config syntax (for example retryable_response_codes: 503).

**Which issue(s) this PR fixes**:
Fixes #5149

**What this PR does / why we need it**:
In YAML config syntax, a single scalar value for an array option is
rejected. For example `retryable_response_codes: 503` fails with `array
required but got 503`, while the classic syntax
`retryable_response_codes 503` works fine. The difference is that the
classic path delivers the value as the String `"503"`, which
`Config.array_value` already splits into `["503"]`, whereas YAML hands
it over as a bare `Integer` that falls straight through to the "array
required" check.

This wraps a non-String, non-Array, non-Hash scalar into a one-element
array so both config syntaxes behave the same way. The wrapped value
then flows through the existing `value_type` coercion, so
`retryable_response_codes: 503` becomes `[503]` just like
`retryable_response_codes: [503]` does. A Hash still raises as before,
so an accidental mapping under an array option is not silently accepted.

I could not run the full suite locally (my Ruby is 2.6 and Fluentd needs
3.2), so I verified the logic by tracing the exact `array_value` path
and reproducing it in isolation; CI should confirm. I added test cases
in test/config/test_types.rb covering a bare integer with and without
`value_type`, and that an existing array is left untouched.

**Docs Changes**:
None.

**Release Note**:
Fix a config error when a single scalar value is given to an array
option in YAML config syntax (for example `retryable_response_codes:
503`).

---------

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
Signed-off-by: arpitjain099 <arpitjain099@gmail.com>
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
@Watson1978 Watson1978 added this to the v1.19.4 milestone Jul 13, 2026
@Watson1978
Watson1978 merged commit e71abac into v1.19 Jul 13, 2026
18 checks passed
@Watson1978
Watson1978 deleted the backport-to-v1.19/pr5413 branch July 13, 2026 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants