fix(redis-schema): copy policy schemas instead of mutating shared tables

[janiussyafiq]

Description

apisix/utils/redis-schema.lua exports policy_to_additional_properties (the shared redis / redis-cluster schema tables) for reuse by limit-count, limit-req, and limit-conn. limit-conn's key_ttl variants were derived by mutating those shared tables in place at module load:

local limit_conn_redis_schema = policy_to_additional_properties["redis"]
limit_conn_redis_schema.properties.key_ttl = {
    type = "integer", default = 3600,
}

Because the table is shared, key_ttl (and its default of 3600) leaked into the base tables seen by every other consumer. Observable effect: limit-count and limit-req confs silently gained a key_ttl = 3600 field during schema validation, even though neither plugin understands the property. A consumer-side core.table.deepcopy(redis_schema.schema) doesn't help — by load time it copies the already-mutated tables.

Changes

• apisix/utils/redis-schema.lua — derive limit-conn's key_ttl variants from core.table.deepcopy of the shared base, then add key_ttl to the copy. The shared redis / redis-cluster tables stay clean. deepcopy is the schema-derive idiom already used by limit-count, and it yields a fully independent tree so future nested edits cannot leak back into the shared base.
• apisix/plugins/limit-req.lua — limit-req bound redis_schema.schema directly (a live reference to the shared module table). It only reads it today, but the alias is a latent footgun: any future in-place mutation reachable through limit-req would poison every other consumer. deepcopy the schema at load time so limit-req owns an independent copy, matching limit-count and ai-cache.

Behavior

• limit-conn is unchanged: key_ttl still accepted, default 3600 still applied.
• limit-count / limit-req confs no longer get a foreign key_ttl injected. A stray explicit key_ttl on those plugins is still tolerated (their schemas do not reject additional properties); it is simply no longer injected.
• Backward compatible.

Tests

t/utils/redis-schema.t:

• one block loads limit-conn first (so any shared-table leak would be visible) and asserts limit-count / limit-req confs across redis and redis-cluster do not gain key_ttl;
• a second block pins limit-conn's own behavior (default 3600 applied, explicit value honored).

Which issue(s) this PR fixes:

None (pre-existing latent bug found while building on redis-schema).

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change (no doc change needed: internal schema utility; user-facing behavior unchanged)
• I have verified that this change is backward compatible

[Copilot]

Pull request overview

This PR fixes a schema cross-contamination bug in apisix/utils/redis-schema.lua where limit-conn extended Redis policy schemas by mutating shared tables at module load time, causing unrelated plugins (e.g., limit-count, limit-req) to unexpectedly inherit key_ttl (and its default) during schema validation.

Changes:

• Build limit-conn’s Redis / Redis Cluster schema variants via a copied properties table (instead of mutating the shared base tables).
• Add regression coverage to ensure key_ttl is not injected into limit-count / limit-req configs even when limit-conn is loaded first.
• Add assertions that limit-conn still applies key_ttl defaulting and honors explicit key_ttl.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
apisix/utils/redis-schema.lua	Avoids mutating shared Redis policy schema tables by creating limit-conn-specific variants with copied properties.
t/utils/redis-schema.t	Adds regression tests to prevent key_ttl leakage into other plugins and to pin limit-conn’s key_ttl behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.