dispatcher flush listeners get triggered when a replication/publish request get initiated. In your case no activation, hence no dispatcher flush. You need to publish the page after XF change to get cache updated or write your own listeners.
The exact behaviour of the dispatcher in this situation will depend on your configuration:
Is the dispatcher configured to use TTLs (via the `/enableTTL` setting)?
Or, is it using .stat file based invalidation with a dispatcher flush agent?
In case #1 above, the time-to-live on the content in question (often set with the ACS AEM Commons Dispatcher TTL feature) will need to expire before the page will be "refetched" from the publish tier.
In case #2, .stat files will be "touched" in the cache (to update their last modified timestamp) when the dispatcher flush request is received. The exact stat file(s) which are touched will depend on the `/statfileslevel` configuration. A value of "1" in this case should work, but may cause additional unnecessary load on the publish tier by re-rendering pages which are otherwise unrelated to the published XF.
Another approach to case #2 would be to leverage the ACS AEM Commons Dispatcher Flush Rules feature to create "smarter" flushing schemes, which could flush your HTML content at specific paths when an XF is published.
AEM does not provide out of the box solutions to flush (re-activate) pages that have a reference to the experience fragment. You need to create your own solution.
One technique can be, on a non-heavy load website, After re-publishing an experience fragment, you can contact your cloud engineering team to flush the entire cache of your website. But keep in mind, the CPU consumption of your publishers will be affected negatively, especially if you have heavy user activity at the given time.
Another technique, as a quick solution for clearing experience fragment cache, is to have the authors use the touch UI, "manage publication", to republish all pages. However, this action will also publish site pages that are currently being edited.
We ran into a similar issue, where the fragment is used in multiple pages, obviously it's a big pain having to re-publishing all of the pages whenever the fragment is changed. Is there a config that would invalidate all of the pages whenever the fragment's updated?