Plugins/DAO: incorrect function field reassignment

[marc-charpentier]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

Kong 2.8.1

Current Behavior

Hello,
In order to load a new plugin entity, a worker executes the Plugins.select_by_cache_key function (call to kong.db.plugins:select_by_cache_key(...), which delegates the load to DAO:select_by_cache_key, and checks whether the core.009_200_to_210 migration was executed previously.
If yes, before returning the loaded entity, the Plugins.select_by_cache_key function tries to self-replace by the DAO's one, but it doesn't work because the assigned field's object isn't the right one.
As an impact, an important extra latency (kong) is added to the plugin's load one, for each request involving such load.

Expected Behavior

Once a worker as ensured that the core.009_200_to_210 migration was executed, it should no longer recheck for any plugin updated / created afterward.

Steps To Reproduce

Problem encountered with Kong in "traditional" role.
On a local VM environnement (Kong and Cassandra containers), extra latency is about 10-15 ms, but on an integration environment (production-like with multi-DCs/multi-nodes Cassandra and Kong clusters), extra latency is about 500 ms.

Steps to reproduce (local environment):
- Start Kong with one single nginx worker.
- Use the Admin API to create a route (hosts[]=localhost) and a request-termination plugin on it (message=OK&status_code=200).
- Curl the route with -i switch in order to check the X-Kong-Response-Latency header:
  - Expected value: 0-2 ms.
  - Real value: 10-12 ms.
From now the request-termination plugin is in the cache.
- Curl again the same route, X-Kong-Response-Latency should be about 0-2 ms.
- Update the request-termination plugin (message=Hello).
- Curl again the same route, X-Kong-Response-Latency should be again about 10-12 ms.

On the integration environment, the X-Kong-Response-Latency value was about 500 ms for the first response after plugin creation/update.

Anything else?

To confirm that Plugins:select_by_cache_key function never succeeds to disable itself, I also added a notice message in its code, just before the instruction that should do the self-disabling. It should have logged the notice message only once (per worker, provided plugin is created/updated as many times as there are workers), but it did logged it for the first response after each plugin creation/update.

[jschmid1]

I see that @bungle referenced this issue in #8896. Could you maybe have a look at this and confirm if that addresses that issue?

[bungle]

@jschmid1, I think @marc-charpentier already answered what they decided to do here:
#8789 (comment)

TL;DR; they decided to do what #8896 does.

[marc-charpentier]

Added #8789 (comment)