AlinsRan opened a new pull request, #13725:
URL: https://github.com/apache/apisix/pull/13725
### Description
Fixes #13593
An unpinned `lua-cjson` declared by a transitive dependency (currently
`lua-resty-openapi-validator`, but any dependency could do it) gets installed
into `deps/`. Because `deps/` precedes OpenResty's `lualib` in `package.cpath`,
`require("cjson")` loads that copy instead of the one bundled with OpenResty.
On arm64 the deps copy (2.1.0.10) re-encodes empty arrays as invalid JSON — the
symptom reported in #13593.
Removing the declaration from one rockspec (the openapi-validator route)
only treats the current source. The root cause is the cpath order: **any**
dependency that drops a cjson into `deps/` reproduces this. This fixes it at
the resolution layer instead.
`apisix/patch.lua` `_M.patch()` is the first place cjson is required. Right
before that require, reorder the `lualib` entries of `package.cpath` ahead of
`deps/`, so the bundled cjson always wins regardless of what lands in `deps/`.
`lualib` is already on the cpath (via `;;`), just after `deps/` — this only
moves it forward. Verified the only overlap between `lualib` and `deps/` is
`cjson.so` itself (`lualib` ships only `cjson.so` and `librestysignal.so`), so
nothing else changes resolution.
Timing is safe: cjson is not loaded before `require("apisix")` (checked),
and `resty.core` does not require it, so the reorder at the top of `_M.patch()`
runs before the first require — no `package.loaded` caching to fight.
### Tests
New `t/core/cjson-bundled.t` asserts the runtime resolves cjson outside
`deps/`. It fails on master today (`cjson resolved from deps:
.../deps/lib/lua/5.1/cjson.so`) and passes with this change (`from bundled`) —
committed as a separate test-first commit. Verified discriminating: reverting
the patch turns it red again.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
