Possible query cache regression

[SerkantKaraca]

Started on 7/21 around 2pm PST I’m observing query results are being cached for 20 seconds and served to other computers when search queries are using the same search phrase but different since_id and/or max_id query parameters.

Scenario:

1. Client A queries for a search phrase with specifying since_id and max_id values. This query returns 100 statuses which is the expected result set.
2. Client B on a different computer/IP queries for the same search phrase with specifying DIFFERENT since_id and max_id values. This query returns 0 status which is also the expected result set.
3. When client A issues the same identical query from step 1 this time it also gets 0 result where as we’ve already confirmed this query returns 100 statuses at step 1.
4. If client A keeps querying every second the results return back to normal exactly 20 seconds later which indicates some sort of cache expiration.

After spending couple of hours on this issue I’ve figured out passing different count values in the same phrase queries helps. It seems count parameter is used in the cache hashkey calculation and a different value results in a cache miss.

[SerkantKaraca]

Here’s a sample output from client A of the given scenario above. The client runs a simple loop which issues same identical query every 2 seconds. The correct result set returns 100 statuses. The 20 seconds time window where the results count goes to 0 starts when client B issues a query which returns 0 statuses. The sample shows 2 different cache corruption windows.

2014-07-23 07:53:29 count: 100
2014-07-23 07:53:32 count: 100
2014-07-23 07:53:35 count: 100
2014-07-23 07:53:37 count: 0
2014-07-23 07:53:39 count: 0
2014-07-23 07:53:41 count: 0
2014-07-23 07:53:43 count: 0
2014-07-23 07:53:45 count: 0
2014-07-23 07:53:48 count: 0
2014-07-23 07:53:50 count: 0
2014-07-23 07:53:52 count: 0
2014-07-23 07:53:55 count: 100
2014-07-23 07:53:57 count: 100
2014-07-23 07:54:00 count: 100
2014-07-23 07:54:03 count: 100
2014-07-23 07:54:05 count: 100
2014-07-23 07:54:08 count: 100
2014-07-23 07:54:11 count: 100
2014-07-23 07:54:13 count: 100
2014-07-23 07:54:16 count: 100
2014-07-23 07:54:18 count: 0
2014-07-23 07:54:21 count: 0
2014-07-23 07:54:23 count: 0
2014-07-23 07:54:25 count: 0
2014-07-23 07:54:27 count: 0
2014-07-23 07:54:29 count: 0
2014-07-23 07:54:31 count: 0
2014-07-23 07:54:34 count: 0
2014-07-23 07:54:36 count: 0
2014-07-23 07:54:39 count: 100
2014-07-23 07:54:41 count: 100
2014-07-23 07:54:44 count: 100
2014-07-23 07:54:47 count: 100
2014-07-23 07:54:49 count: 100
2014-07-23 07:54:52 count: 100
2014-07-23 07:54:55 count: 100
2014-07-23 07:54:58 count: 100

[andypiper]

Thanks for this detailed report, I’ll raise a ticket to investigate internally.

[andypiper]

We believe this issue should now be resolved. Thank you for your patience, and apologies for the inconvenience.