bug: issues with numerical precision

[chao6118]

Current Behavior

local core = require("apisix.core")
local redis = require("resty.redis")

return function(conf, ctx)
core.log.error("=====post===", tostring(ctx.conf_version), "===")

local result = "{ \"aaa\" : 9007199263392129  }"
local aaaa = core.json.decode(result)

core.log.error("=====aaaaaaaaaaaa===", tostring(aaaa.aaa), "===")

--设置返回
ngx.arg[1] = core.json.encode({aaa=aaaa.aaa})
ngx.arg[2] = true

return

end 数据精度问题 9007199263392129这个会返回 {"aaa":9007199263392128} 请问有什么办法可以处理高精度问题 如java 那种long类型的数字

Expected Behavior

可以处理高精度问题 如java 那种long类型的数字

Error Logs

{"aaa":9007199263392128} 精度丢失

Steps to Reproduce

apisix3.14.1

Environment

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

[Baoyuantop]

Thanks for reporting this. Based on the reproduction you shared, core.json.decode currently converts JSON numbers into Lua numbers, and APISIX's core.json is essentially a thin wrapper around cjson.safe.decode. Because of that, a value like 9007199263392129 can lose precision once it is decoded into Lua/OpenResty and then encoded again, which is why you are seeing 9007199263392128.

From the current APISIX code and documentation, this looks closer to a current limitation / question than a standalone APISIX bug regression. For example, the http-dubbo documentation already mentions that precision differences between Lua and Java may cause discrepancies, and it recommends using pre-serialized bodies to avoid precision loss.

For now, the safer workarounds are:

1. send such long / ID fields as strings; or
2. keep the body pre-serialized and avoid decoding large integers into Lua numbers before forwarding or rewriting it.

If your expectation is that APISIX should support a bigint-preserving JSON mode, please share the expected behavior in more detail (for example, whether returning large integers as strings is acceptable, which scenarios should be covered, and what compatibility changes are acceptable). Then we can evaluate it as an enhancement proposal.

[chao6118]

如果是这样处理 业务的数据都要转成字符串嘛？这是处理的常规手段，这样的话，网关有什么好的处理方案嘛？你不能说用了某个库有问题，让我们来改变修改吧

[Baoyuantop]

@chao6118 I understand your concern. Let me provide a bit more technical context and some practical suggestions:

Why does the precision loss happen?

APISIX is built on OpenResty/LuaJIT, where Lua's number type is an IEEE 754 double-precision float. The maximum integer it can represent exactly is 2^53 (9007199254740992). Your value 9007199263392129 exceeds this threshold, so precision is already lost the moment cjson.decode converts it into a Lua number — the subsequent encode just exposes the issue. This is an inherent limitation of the Lua runtime, not unique to APISIX.

Practical approaches:

1. Avoid unnecessary decode/encode cycles. If your plugin only needs to modify certain fields in the body, consider using string-level operations (e.g., ngx.re.gsub) on the raw body instead of going through a full JSON decode → encode round-trip. This avoids precision loss entirely.

2. Transmit large integers as strings. Have your upstream service serialize long/ID fields as strings (e.g., "9007199263392129" instead of 9007199263392129). This is a widely adopted practice in cross-language API communication — browsers and JavaScript have the same 2^53 limitation.

3. Enhancement proposal. If you believe APISIX should natively support big-integer preservation (for example, a decode_number_as_string option), feel free to open a separate enhancement issue with details on: (a) the exact behavior you expect, and (b) what compatibility trade-offs are acceptable. The community can then evaluate an implementation plan.

This is indeed a pain point, but it requires careful design within the current Lua-based stack. Looking forward to your feedback.