Currently query knobs are not part of the plan cache key, which may cause the stale plan being used, even though new plans may be available.

QuerySettings was having similar issue, which got solved by integrating QuerySettings as part of PlanCacheKey

This is an old behavior, recently encountered as part of HELP-83558:

Case 1: When changing a query knob, specifically for this case internalQueryMaxScansToExplode the plan cache is not invalidated. This caused a confusing scenario for the customer: For Node 00, all queries were using a plan benefiting from the parameter change, while on node 02, one query was "stuck" with the "wrong plan". A few hours later most likely a query with a specific filter nudged the planner during a trial to use the "good" plan, and then all queries were executing with the optimal index.

Additionally, we want to remove the old solution where we explicitly clear out the plan cache on query knob changes via the on_update hook.