Cache does not invalidate when data changes

[jbkolze]

Describe the bug
The cache for time series data does not invalidate when the data within the request changes. Affects at least GET and POST /timeseries (though quite possibly other endpoints as well). Tested in 2026.01.23-develop.

Expected behavior
If I make a GET /timeseries request for data on Jan 5-7 and subsequently make a POST /timeseries request to add data on Jan 6, a subsequent GET /timeseries request for the same data should invalidate the cache and respond with current data.

To Reproduce
Steps to reproduce the behavior:

(Within a relatively short timeframe to avoid cache becoming stale, and assuming that specific cache-control headers are not included)

1. Make a GET /timeseries request for a specific time window
2. Make a POST /timeseries request to edit data for the same time series within the same time window
3. Make the original GET /timeseries request again
4. Note that the response has not changed from the original request

CDA Version (please complete the following information):

• Version 2026.01.23-develop

Additional context
When known to potentially cause issues, the cache can sometimes be disabled by including custom Cache-Control headers with the request. However, this can be unreliable due to headers being blocked by CORS settings in some environments (e.g. CWBI). The ideal solution would be to incorporate "smarter" cache handling.

[rma-rripken]

This is important but its also going to be difficult to completely fix.

We use per-endpoint Cache-Control plus client-side OkHttp caching in CDAC, which works well for quick re-opens but doesn’t detect server-side changes.
Our current Entity Tag (ETag) is a response hash, which saves bandwidth (304) but not server CPU because we still build the full payload to re-hash (complete rehydrate).

We haven't come up with a cheap way for CDA to know if the database has changed. If we had that ETags would become massively more helpful and CDA could signal that data had changed without a full rehydrate. Maybe something like Oracle SCN / ORA_ROWSCN, a per-entity MAX(updated_at), or CDC signals? Maybe there is something in GoldenGate that can be reused?

OkHttp's default cache doesn't have fine-grained cache control but we could probably add it. Having the client dump cache would help with the "I Just wrote data" issue but it doesn't help cross-client scenarios. With aliases it wouldn't be possible to know which timeseries to dump so as soon as you wrote any timeseries data the client probably needs to dump all the timeseries cache.

We could probably be smarter about how we set the cache-control window. If its an end-point that accepts a time-window and the window includes "now" it seems like we should make the TTL very short - 5s?

As requests go further back in time it seems like the TTL could get longer.

[MikeNeilson]

The time window based one seems reasonable.

That said, worth pointing out that we are accessing the queue data for the new RSS feed, might be able to do something similar, or since it's for internal use just create a subscriber (though with a different data source pool) that is used to invalidate that cache on changes. The actual queue messages are rather small, just ts id, and I think code, and the range, so if we keep and in memory cachce on ts_code, we take care of the alias. If we also key on the query ranges we can do a lot of pre-checks before we talk to the database to get more... also seems like that might pair well with future "actual cache engines."