membphis opened a new issue, #14114: URL: https://github.com/apache/apisix/issues/14114
### Current Behavior The dependency upgrade in [#14088](https://github.com/apache/apisix/pull/14088) changes `lua-resty-openidc` from 1.9.0-1 to 1.9.3-1. Under the conditions below, one `openid-connect` introspection request invokes the same failing discovery HTTP transport **4 times instead of 2**. Conditions: - A bearer token is supplied and the introspection flow is used. - `introspection_endpoint` is omitted, so the URL must come from discovery. - Discovery is unavailable or returns an invalid response, with no usable cached discovery document. - Introspection caching is enabled, the `introspection` shared dictionary exists, and this request becomes the coordination owner. This is an outage/failure-path performance issue, not a general doubling of successful request latency. The duplicate discovery work happens inside `lua-resty-openidc`, during cache-key construction, coordination, and endpoint resolution. ### Expected Behavior Resolve the endpoint once per introspection invocation. Preserve cache rechecks, lock-generation handoff, fail-closed validation, structured error responses, and the ability for a later independent request to retry discovery. ### Reproduction and Evidence Upstream tracking: https://github.com/zmartzone/lua-resty-openidc/issues/579 The upstream issue includes a complete deterministic reproduction using unmodified modules from pinned commits and a failing HTTP transport: ```text 1.9.0: discovery_request_uri_calls=2; failure=nil 1.9.3: discovery_request_uri_calls=4; failure=endpoint_unavailable ``` The v1.9.3 tag and master both resolved to `a4755bffdfe7b122123c972ce5820529c3e83fdc` when checked. The four attempts are the initial cache lookup, coordination-key construction, post-lock cache recheck, and final endpoint resolution. A request-local guard prototype reduced 4 attempts to 1 while preserving the same 503 failure classification; 13 fixture-backed control cases passed, including inactive-token rejection and coordination fallback. This is not a full NGINX integration test or a merged fix. ### Follow-up Plan - Track and fix endpoint-resolution reuse in upstream `lua-resty-openidc`. - After an upstream fix is released, update the APISIX dependency. - Add an APISIX regression with no explicit introspection endpoint: assert the discovery call count and the 503 response for the failure path. - Also retain coverage for successful discovery, explicit endpoints, cache hits, invalid/inactive tokens, concurrent coordination, and later-request recovery. For opaque-token introspection deployments that already know the endpoint, explicitly configuring `introspection_endpoint` avoids this particular repeated-discovery path without bypassing token validation. ### Merge Decision This is a known, non-blocking follow-up for #14088. The dependency upgrade and its correctness/concurrency improvements may proceed. This issue does not request removal of the necessary cache rechecks or a downstream copy of the upstream coordination implementation. ### Environment - APISIX PR #14088, reviewed head `92640967b6fd5309916fb36fe6856fe5d185733c`. - lua-resty-openidc 1.9.3-1; comparison baseline 1.9.0-1. -- 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]
