The data service makes potentially expensive queries, so the responses are cached. However, if a duplicate request comes in prior to the initial one making it to the cache, they will both be executed. Since this is potentially the expected case due to a gateway timeout, we should make sure it's handled gracefully:
After/if we find that the response is not cached, we should atomic/put (note, not sure of the redis term, but a write only if empty) write a ~5 min expiry flag for the scenario that the request is in flight.
If that write fails because it's already there, then we should wait on the cache for ~25 seconds before returning a timeout error or the actual data. The client should repeat the request in the case of a timeout.
If it succeeds, then proceed to do the query
After writing the to cache, clear the flag, or just let it expire.
(related to https://github.com/global-electrification-platform/explorer/issues/211)
The data service makes potentially expensive queries, so the responses are cached. However, if a duplicate request comes in prior to the initial one making it to the cache, they will both be executed. Since this is potentially the expected case due to a gateway timeout, we should make sure it's handled gracefully: