search

darkweak / souin

An HTTP cache system, RFC compliant, compatible with @tyktechnologies, @traefik, @caddyserver, @go-chi, @bnkamalesh, @beego, @devfeel, @labstack, @gofiber, @go-goyave, @go-kratos, @gin-gonic, @roadrunner-server, @zalando, @zeromicro, @nginx and @apache
https://docs.souin.io
MIT License
718 stars 56 forks source link

Invalidate cache in default project api platform #541

Closed g-ra closed 3 months ago

g-ra commented 3 months ago

There appears to be an issue with the cache invalidation process within our application. The cache is not being invalidated immediately upon data entry or modification, leading to outdated data being served to the users. This issue was observed and demonstrated in the following video: Loom Video.

Steps to Reproduce:

Enter or modify data in the application. Check the cache to see if it has been invalidated. Observe that the cache is still serving outdated data. Expected Behavior: The cache should be invalidated immediately upon any data entry or modification to ensure that users are always served the most up-to-date information.

Actual Behavior: There is a noticeable delay between the data entry/modification and the cache invalidation, causing outdated data to be served.

Questions:

How much time typically passes before the cache is invalidated? Is there a way to configure or influence the cache invalidation timing to ensure immediate updates?

Possible Solutions:

Investigate the cache invalidation logic to ensure it triggers immediately upon data changes. Provide configuration options to set the cache invalidation timing. Attachments:

Link to the Loom video demonstrating the issue

darkweak commented 3 months ago

Hello @g-ra the commit 743a3a45f4f3d3509def3d2654c0a0eda1f49636 fixes that. You canary the patch with

    --with github.com/darkweak/souin/plugins/caddy@743a3a45f4f3d3509def3d2654c0a0eda1f49636 \
    --with github.com/darkweak/souin@743a3a45f4f3d3509def3d2654c0a0eda1f49636
g-ra commented 3 months ago

yeah, works fine