Building a cache key based on filters causes new events to be missing

[gasaichandesu]

Let's assume the following case: user is creating a new event, there is no exceptions and user is trying to fetch his events again. However he is not going to see his newly created event for couple of minutes. More specifically, 240 seconds

After a quick look at a nostpy codebase I found out that it uses caching. Every time data is fetched, the result is stored in Redis and keyed by serialized filter.

This is the part of code which caches results based on provided filter

 parsed_results = await subscription_obj.query_result_parser(query_results)
            await redis_client.setex(cache_key, 240, orjson.dumps(parsed_results))

For example, if following filter is used

{
    "kinds": [0],
    "authors": ["pubkey"]
}

then for the following 4 minutes result of this request is going to be cached and for the same filter the same set of results will be returned

I am interested why was this caching strategy introduced and what workaround can we use in our client. Because of this issue user cannot see his newly created events until cache is dismissed

[UTXOnly]

I intentionally set this caching strategy because many clients make redundant and expensive queries whenever a page is refreshed. That said, I’m exploring a few different options for improving this, since I agree it can be problematic.

One easy solution would be to introduce a user configuration setting to either disable caching entirely or allow users to reduce the cache expiry period.

A more involved—but potentially better—approach would be to implement a background migrations service. This service would proactively run the top 10–20 most common queries (as identified via a database monitoring tool) and cache the results in Redis with a shorter expiry period.

I’d love to get your input on this, especially around the types of events you’re looking to add and then immediately query afterward.

[gasaichandesu]

Thanks for your response. I agree that removing caching completely is not a solution. For now we found a workaround - for every request we add or subtract a few seconds to since field. It does not affect results but avoids caching which is expected

As a more reliable solution I would prefer an easy solution mentioned by you - just a simple environment variable which allows to control cache expiry period