Config: accept a bare scalar for an array option in YAML syntax

[arpitjain099]

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).

[kenhys]

nitpick: conversion rule was changed, so it might be better to add another test case such asa assert_raise(Fluent::ConfiguError.new("array required but got #{val.inspect}") for known types.

Could you afford to write such a test case?

[arpitjain099]

Responded

[arpitjain099]

Thanks for the review, good call. I've added a test case asserting that a Hash input still raises Fluent::ConfigError with the array required but got #{val.inspect} message, so the scalar-wrapping change doesn't accidentally accept a mapping under an array option. It covers a hash both with and without value_type. Verified green on Ruby 3.4.

[Watson1978]

One concern about the new else branch.
it wraps any object that isn't a String/Array/Hash, including Symbols, Time objects, or arbitrary objects that would previously have been rejected with ConfigError.
That defensive behavior is worth keeping for unexpected types.
Since the scalars Psych actually produces here are Integer/Float/true/false (nil is handled by the early return), how about limiting the wrapping to those types?

elsif val.is_a?(Numeric) || val == true || val == false
  [val]
else
  val  # anything else still raises "array required" below
end

This fixes the reported issue while preserving the existing error for genuinely invalid values.

[arpitjain099]

Good catch, thanks. You're right that the broad else swallowed types that should stay rejected. I've narrowed the wrapping to just the scalars Psych actually produces here (Numeric, true, false; nil still returns early), so anything unexpected like a Symbol or a Time now falls through and raises array required as before. Added test cases for a bare float/true/false wrapping, plus Symbol and Time still raising alongside the existing Hash case. Green on Ruby 3.4.

[Watson1978]

The updated version looks good to me.

One non-blocking suggestion, it would be nice to also have an end-to-end test in test/config/test_yaml_parser.rb that exercises the actual YAML pipeline (e.g., a config with retryable_response_codes: 503 reaching a plugin's array parameter). The unit tests here verify ARRAY_TYPE directly, but the premise of this fix — that the YAML parser hands a bare Integer to the type-conversion layer — is only implicitly covered. If the YAML parser ever starts stringifying scalar values, an E2E test would catch the regression.

[arpitjain099]

Thanks @Watson1978, good idea. Added two tests to test/config/test_yaml_parser.rb that go through the real YAML pipeline: a config with retryable_response_codes: 503 on a match section, parsed with YamlParser and fed to a Configurable with an :array param (value_type: :integer). The bare scalar comes out as [503], and a [502, 503] sequence still works as before. Ran the file locally on Ruby 3.3, 33 tests green.