Problem with Cache for Dynamic Blocks

Apparently the problem is permanently solved if you trigger the following as a guest. (once)
$this->cacheBackend->invalidateAll();
I don't understand it. After you've done that, you can add new views, new content types and it updates everything immediately (Blocks). The question now is, does that fix it or does it break something?

I generated the codes in the attachment with claude.ai and modified them slightly. You can generate a token URL (/admin/config/system/av-cache-flush), first save the form so that you can use the link afterwards, then run it as a guest (without logging in). V1 only has the code mentioned above and V2 deletes even more caches or executes various codes to delete various caches. (if necessary, look at CacheFlusher.php - flushCache / flushAllCaches)

The issue is that cached content in Views blocks doesn’t invalidate on the basis of the current date, correct?

It definitely doesn’t, and I don’t know whether this is expected behavior. Neither date nor time are available cache contexts → .

We work around this with various tricks.

The workarounds we use usually are setting the max-age cache option. For that to really work you need #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache → . If what I am writing here makes sense with this issue I think it may be a duplicate of 🐛 Views' cache with relative date filter is not invalidated when needed Active . Can you verify?

At a minimum this needs a title and summary update.

The main problem is that blocks do not update, as in the example when a news list is displayed where content is only supposed to be visible in 1 minute, i.e. in the future, and the 1 minute passes, it is not displayed afterwards. The effect is particularly noticeable as a guest. (Time less than or equal to now)

I have had various situations, but they all lead to the same problem:
- A block created using a module where max-age was set, it should not actually save this, but it has no effect and is cached
- Calendar list, using view, here the cache option was removed, but it is saved here too
- Various other variations using some caching modules, e.g. to deactivate the cache of a page, but here too this did not lead to the desired result

The problem here is more that when you are logged in, the pages are sometimes actually updated, but as a guest they remain old. As written above, the guest only has a fresh page if the cache is completely emptied or new content is created, and it doesn't matter what content it is, i.e. it can be of any content type, it can also be contextless. A cron job does not trigger an update with the Drupal Core crone jobs.

Strangely enough, if I execute the code I posted, i.e. once, then I can create new future news and when the time passes this is immediately displayed.

I haven't done a long-term test yet, but whether I create content or new views with blocks and integrate them, everything is up to date, that's mindblowing and don't understand the mechanics.

Note: The focus here should be on the guest, i.e. an unregistered user.

I think it's basically the same as the post you linked: https://www.drupal.org/project/drupal/issues/2352009 →
max-age manipulation is not the solution here.

This seems a duplicate of 🐛 Views' cache with relative date filter is not invalidated when needed Active , correct?

This is the same case, but it does not only affect views but all blocks that are dynamic. It is also possible that a block has been created that has nothing to do with the views module.

The fact remains that there is neither a date nor a time cache context in Drupal. Max-age is a way to implement this but using it requires #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache → to work.

The steps to reproduce involve Views or I am missing something.

There could be something for this issue to be about that doesn’t duplicate other issues, but what will that be?

It would be possible to add date/time cache context, maybe different versions with per hour and per 15 minute granularity. Should be added to auto-placeholdered cache contexts if we do that.

I tried to make the effect reproducible, so I used a block of module views. But it basically affects everything. I created a custom block that fills a slider via an interface and doesn't update. Or at least it does when logged in, but not when guest.
custom block like this:
https://www.drupal.org/docs/creating-modules/creating-custom-blocks/crea... →

I wanted to test it again today:

- Currently it was 2:43 p.m. and I set the time to 2:45 p.m.
- Entry in list as: Admin not visible; Guest not visible
- It was now 2:45 p.m. - Entry in list as: Admin visible; Guest not visible
- As a guest I triggered $this->cacheBackend->invalidateAll(); and entry in list as: Guest was visible

now

- Currently it was 2:50 p.m. and I set the time to 2:52 p.m.
- Entry in list as: Admin not visible; Guest not visible
- It was now 2:52 p.m. - Entry in list as: Admin visible; Guest visible!!!

the positive effect after $this->cacheBackend->invalidateAll(); only lasts for a certain time. Today's test was again with old symptoms. That means that a certain time after $this->cacheBackend->invalidateAll(); everything is always displayed live, as it should.

I suggest to mark this a duplicate of #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache → and 🐛 Views' cache with relative date filter is not invalidated when needed Active