We're seeing this issue when we import config during our site deployments.
When the deployment first runs and imports the config, the breadcrumbs show on some but not all nodes for anonymous users. A cache rebuild is part of the deployment scripts. (The fun bit is) it's a different set of nodes that show without the breadcrumbs after each deployment. At this stage, an authenticated user can see breadcrumbs on all nodes. It's just anonymous users that see them intermittently.
Once an authenticated user updates a node, the breadcrumbs work across all nodes for all user types (I believe this was the result of https://www.drupal.org/node/2827653).
It'd be great to get a solution that solves the issue after a fresh import. Config deployments are being done using drush config-import command on an existing site database.
Comments
Comment #2
Marishka_ commentedComment #3
rphair commentedThis sounds like the same underlying problem as https://www.drupal.org/node/2851688 though I don't want to close this as a duplicate since the other refers explicitly to the UI while this issue doesn't.
https://www.drupal.org/node/2827653 - where we came as close as ever to a predictable caching implementation - added the menu plugins of all items in the breadcrumb trail as cacheable dependencies. If this is not enough then I see nothing can do to fix it that wouldn't be far outside the scope of a contrib module.
So I'm linking these two issues together & will search for a core issue that refers to the caching problem of the menu subsystem as documented, creating one if necessary and linking it here. In the meantime it would be good to know if upcoming Drupal 8.3 has relevant bug fixes for the cache dependency of menu plugins.
Comment #4
rphair commentedBTW the other issue appears fixed in recent updates to Drupal 8.2 - so it is just this issue that is the basis for the enquiry to the core maintainers of the menu subsystem. If I can refer any of their questions to the original poster, that will be very helpful since I don't have the right setup to reproduce this (yet).
Comment #5
Marishka_ commentedOk great - we've got plans to update to 8.2.7 in the next couple of weeks so I'll report back if that solves it. Thanks for the reply!
Comment #6
Marishka_ commentedWe've not seen this one since updating to 8.2.7 or 8.2.8. Always hard to say for sure with an intermittent bug, but I think this one can be marked as fixed. Thanks for the support!
Comment #7
rphair commentedHappy days! Was hoping for a report like this, thanks for notification.
Comment #9
rphair commentedp.s., patch now available to work around plugin cache problems upstream; could you please test either with dev version or with 8.x-1.2 plus patch at 2887053->#3? If reports of fixing all caching problems will release as 8.x-1.3.