bug: String environment variable value is casted tonumber if contains a number in standalone mode

[ravillarreal]

Current Behavior

Im using apisix, with standalone mode, in which ive noticed that when a env variable is set in apisix.yaml file, if the value is a number, it will automatically convert it to number, and this causes an error if the number is bigger than Lua's double, for example (extracted from my apisix.yaml file):

plugin_configs:
  - id: 1
    plugins:
      openid-connect:
        client_id: "${{APISIX_OIDC_CLIENT_ID}}"

Note the double " in the env var, still it doesnt treat it like an string

The APISIX_OIDC_CLIENT_ID is set to "356002209726529540" but the value is casted to "client_id":3.5600220972653e+17

This is because this code in apisix/cli/file.lua

apisix/apisix/cli/file.lua

Line 127 in a269d61

if tonumber(new_val) ~= nil then

Expected Behavior

I expect that the value passed in as "${{var}}" works like an string

Error Logs

2026/01/22 06:11:11 [error] 57#57: *321192 [lua] config_yaml.lua:333: failed to check item data of [plugin_configs] err:failed to check the configuration of plugin openid-connect err: property "client_id" validation failed: wrong type: expected string, got number ,val:

Steps to Reproduce

1. Run APISIX via the docker image
2. Configure it as standalone mode with env variable - APISIX_DEPLOYMENT_MODE=standalone
3. Configure env variable with number inside bigger than lua's double eg "356002209726529540"
4. Set the variable in apisix.yaml in "${{}}" format
5. Get the error, in this case im using openid-connect plugin

Environment

• APISIX version (run apisix version): image: apache/apisix:3.14.1-debian
• Operating system (run uname -a): fedora 43 workstation
• OpenResty / Nginx version (run openresty -V or nginx -V):
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info): standalone mode
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[suryaparua-official]

Hii, I’d like to confirm my understanding of this issue before starting any work.
From what I see, the problem is that environment variable substitution currently performs automatic type casting even when the value is explicitly quoted in YAML.

For example:
abc: 10
xyz: "${{ABC}}"
with: ABC=10

Observed behavior: abc becomes number 10 and xyz also becomes number 10

my understanding:
abc should remain number 10 and xyz should remain string "10", since it is explicitly quoted

This automatic casting can cause schema validation errors in plugins such as
openid-connect, especially when large numeric values are provided via environment
variables (values exceeding Lua number precision).

Before proceeding, I’d appreciate confirmation that Should quoted environment variable substitutions always be treated as strings? and Is limiting automatic type casting only to unquoted substitutions the intended direction?
Once confirmed, I’ll be happy to work on a fix.
Thanks for your time and guidance.

[ravillarreal]

That's correct i havent found official documentation in apisix saying that double quotes must handle values like string, but its more part of the YAML specification i think https://stackoverflow.com/a/69850618, but the real problem is that it is parsing to a numeric value and that is making trouble for numbers greater than lua's limit or if the number must be treated as an string, because it will convert it to scientific notation as in the example

[suryaparua-official]

Yes, agreed. This is expected behaviour caused by YAML type inference and Lua's use of double precision numbers, so its not a lua or APISIX issue.
Since the values are identifiers and not intended for arithmetic, the correct solution is to define them as string at the configuration level by quoted them in YMAL. This prevents numeric parsing, precision loss, and scientific notation when the value reaches Lua.

[Baoyuantop]

This automatic type conversion was initially designed in #2743 to enable users to configure numeric system parameters (e.g., worker_rlimit_nofile) and boolean parameters (e.g., enable_admin) via environment variables. This design targeted core APISIX configuration items within config.yaml.

In a subsequent extension (#6505), to address user requests (#5244), the same resolve_conf_var function was directly reused in the parsing of apisix.yaml for standalone mode. However, this failed to account for the differing usage scenarios between the two contexts. This resulted in environment variables like “${{VAR}}” in standalone mode apisix.yaml being automatically converted to numeric types when their values were pure numeric strings (e.g., “356002209726529540”).

To address this issue, I recommend adding an optional parameter to resolve_conf_var to control whether automatic type conversion occurs, and disabling automatic type conversion when processing apisix.yaml.

[lxbme]

Hi, I would like to work on this issue. Based on @Baoyuantop's suggestion, I plan to add an optional parameter to resolve_conf_var to control automatic type conversion and disable it for apisix.yaml processing. I will submit a PR soon.

[lxbme]

Hi, I've submitted PR #13078 to address this issue.

Following @Baoyuantop's suggestion, I've added an optional parameter to control type conversion and disabled it for apisix.yaml while maintaining backward compatibility.

Please review when you have time. Thanks!