This was first posted to the forum (#2782043), but I guess this a bug :

After a while I get suddenly a 404 error page instead of my node pages (no field added, type=page) in the default language only (accessing it both with paths like /node/{id} or /{node_path}). A cache rebuild solves that.

After a while it seems that the cache entry for my nodes are filled with the 404 error page.

Other things :

  • This is difficult to reproduce, as I need to wait a few days to see 404 pages appear again.
  • I set it to content_translation component issues, because it seems to affect only the default language, and it seems to b what people thhink in the forum.
  • I also have pathauto, redirect on this site
  • I set it to 8.x-dev,
    because I had the bug in quite all versions since release 8.1, and now on release 8.2.3.

Comments

pguillard created an issue. See original summary.

cilefen’s picture

cilefen commented

Is this similar to #2802403: Combination of language negotiation and path aliasing can cause a corrupted route cache, 404s?

pguillard’s picture

pguillard commented

I looks similar, but this not the same diagnostic : my page has no extra fields (Default content type of type "page").

Here is what I get in cache_data before and after clear cache :

Before clear caches (/node/2 gives 404) :

mysql> select * from cache_data where cid='route:/node/2:';
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| cid            | data                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | expire | created        | serialized | tags        | checksum |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| route:/node/2: | a:3:{s:4:"path";s:7:"/node/2";s:5:"query";a:0:{}s:6:"routes";O:41:"Symfony\Component\Routing\RouteCollection":2:{s:49:" Symfony\Component\Routing\RouteCollection routes";a:1:{s:21:"entity.node.canonical";C:31:"Symfony\Component\Routing\Route":1352:{a:9:{s:4:"path";s:12:"/node/{node}";s:4:"host";s:0:"";s:8:"defaults";a:2:{s:11:"_controller";s:48:"\Drupal\node\Controller\NodeViewController::view";s:15:"_title_callback";s:49:"\Drupal\node\Controller\NodeViewController::title";}s:12:"requirements";a:3:{s:4:"node";s:3:"\d+";s:14:"_entity_access";s:9:"node.view";s:7:"_method";s:8:"GET|POST";}s:7:"options";a:5:{s:14:"compiler_class";s:34:"\Drupal\Core\Routing\RouteCompiler";s:10:"parameters";a:1:{s:4:"node";a:2:{s:4:"type";s:11:"entity:node";s:9:"converter";s:21:"paramconverter.entity";}}s:14:"_route_filters";a:2:{i:0;s:13:"method_filter";i:1;s:27:"content_type_header_matcher";}s:16:"_route_enhancers";a:1:{i:0;s:31:"route_enhancer.param_conversion";}s:14:"_access_checks";a:1:{i:0;s:19:"access_check.entity";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";C:33:"Drupal\Core\Routing\CompiledRoute":429:{a:11:{s:4:"vars";a:1:{i:0;s:4:"node";}s:11:"path_prefix";s:5:"/node";s:10:"path_regex";s:24:"#^/node/(?P<node>\d+)$#s";s:11:"path_tokens";a:2:{i:0;a:4:{i:0;s:8:"variable";i:1;s:1:"/";i:2;s:3:"\d+";i:3;s:4:"node";}i:1;a:2:{i:0;s:4:"text";i:1;s:5:"/node";}}s:9:"path_vars";a:1:{i:0;s:4:"node";}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:2;s:14:"patternOutline";s:7:"/node/%";s:8:"numParts";i:2;}}}}}s:52:" Symfony\Component\Routing\RouteCollection resources";a:0:{}}} |     -1 | 1480960569.346 |          1 | route_match | 488      |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

After clear caches (/node/2 gives the node page) :

mysql> select * from cache_data where cid='route:/node/2:';
Empty set (0,00 sec)
derheap’s picture

derheap commented

We also see this in a live site for a university from time to time.
Clearing the cache fixes the problem.
At least I have found an issue about this issue.

cgmonroe’s picture

cgmonroe commented

I have seen this regularly on our multilingual site. As people have said, it seems to be related to specific pages.

I have 4 or 5 of them being monitored by pingdom that alert me if they 404. Clearing Drupal cache and Varnish corrects the problem.

I thought it might be memcache related but because of some problems with memcache crashing, we switched to using the DB for caching. Still get the problem.

It also seems to be cache time related. Initially our site had a long cache time. Then we started seeing 404s and other odd artifacts (like the German main menu which was fine on the DE home page, but would show up with English URLs on a DE product page... the menu labels were in German, but the links were to the English pages. So we set the cache time to 15 minutes and the monitored problems dropped to next to nothing.

When we switched to DB caching from Memcache, we raised the cache time to 1 hour. Now we are seeing problems occur again.

The Apache access logs don't show anything like high load or multiple accesses. Just one access it's fine, the the next it's a 404.

FYI - Running current core (8.3.2 as of this writing) with current versions of contrib modules on Acquia Cloud servers.

Mike Dodd’s picture

Mike Dodd commented

I to am seeing this, did anyone get anywhere.

Can reproduce with cache time set to 1 hour problem is with and without memcache, only looks to be a single node and only seems to effect the default language.

heyehren’s picture

heyehren commented

I seem to have the same issue. When i clear the cache, somewhere on the website a page is going to get the 'page not found' error. When i clear the cache again the error is gone. This affects different pages every time.

Core cache is activated and set to 15 min. I am running a multilingual site on the latest Drupal 8 core. Only the default language seems to be affected.

What i found so far is that when clearing the cache i see a peak in the database requests which sometimes exceed my I/O recourse limits. When this happens the host (in this case GoDaddy) limits the resources on my shared hosting account for some time.

I'm now optimizing the site and adding opcache and memcache to see if this will fix the issue.

michaelkoehne’s picture

michaelkoehne commented

@kleinermann: This won't fix the problem.

We've the same issue. Multilingual page PHP 7.0.20 with APC and OPC. 256M Memory. Drupal 8.3.2.
I've tested it - with activated cache (1h) and also with deactivated cache - the issue still remains.

heyehren’s picture

heyehren commented

@michaelkoehne. Thanks for letting me know. For me this didn't work either. The only way for me to prevent the issue at the moment is to use drush cr to clear the cache instead of clearing it through the Drupal backend.

cilefen’s picture

cilefen commented
Priority: Normal » Major

I am raising this to major.

gagarine’s picture

gagarine commented
Version: 8.0.x-dev » 8.5.x-dev

I have a very similar bug on Drupal 8.5. It seem that translating node make them sometimes not reachable anymore. Clearing the cache fix it.

I have autopath and URL alias (translatable).

Site web is in DE,FR, EN. Default language English, but fall back language is french.

gagarine’s picture

gagarine commented
Priority: Major » Critical
Issue tags: +DrupalWTF

This is critical user and admin can't access the content. The system become unusable from time to time without a cache clear.

catch’s picture

catch
he/him
Primary language English
commented

Note that #2879512: Path aliases can be "forgotten" after a cache rebuild due to race condition in CacheCollector was fixed recently, please make sure if you've reported this issue, that you can still reproduce it in a version with that fix applied.

Additionally, while #2802403: Combination of language negotiation and path aliasing can cause a corrupted route cache, 404s might be a different issue to this one, they're very similar so consider trying patches on that issue, the link field may not be the only way to run into that one.

heyehren’s picture

heyehren commented

After a few weeks i still get the Page Not Found error on random pages.

It doesn't happen on the translations, only on the default language. The strange thing is that i deactivated the cache by setting 'Page cache maximum age' to 'no caching'. CSS and JavaScript aggregation is still active though. It makes no difference. When i clear the cache (drush cr) the pages work again.

This time i have even checked all 50 pages on the website directly after clearing the cache to see if the error occurs straight away. But all pages are initially working. Only after some time (the earliest i saw was about 30 min) the errors start popping up.

It also only happens on the live server. My local test environment works fine, with or without cache activated.

I don't understand enough about the Drupal 8 caching system to have an opinion on this.

I hope someone else can help with the issue.

catch’s picture

catch
he/him
Primary language English
commented
Version: 8.5.x-dev » 8.4.x-dev

The page cache has nothing to do with this, it's corruption of the route cache (see comment #3 for an example).

@kleinermann please confirm the following:

1. Are you using the link field type?

2. What method of language negotiation are you using?

Moving back to 8.4.x because we try to fix bugs in the lowest version affected where possible.

maacl’s picture

maacl commented

Sorry, wrong Post. Comment was ment for https://www.drupal.org/node/2802403.

timcosgrove’s picture

timcosgrove commented

Just to add a voice here: we run a D8 site in 29 languages, and we were seeing this issue. We run US English as our default, serve that from /en/foo aliases, and redirect from /foo aliases to /{prefix}/foo aliases according to language negotiation rules.

We were seeing similar behavior, where in some cases /foo aliases were cached as 404s when the intended destination entity was not translated into all languages, and an untranslated redirect request (i.e. /en-gb/foo) was requested and cached.

We implemented the patch from https://www.drupal.org/node/2802403#comment-12217386 and this appears to have successfully resolved our issues. Of note, for this thread: some of the aliases in question were not contained in link fields anywhere.

https://www.drupal.org/node/2802403 appears to be focused on link fields as that was where the bug was first seen, but the issue does ultimately seem to be with bad route caching, as Catch has said
.

I would probably recommend https://www.drupal.org/node/2834638 (this issue) be closed as a duplicate of https://www.drupal.org/node/2802403 and the title of https://www.drupal.org/node/2802403 modified to reflect that it affects more than link field data. I would defer to Catch here.

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)
Related issues: +#2802403: Combination of language negotiation and path aliasing can cause a corrupted route cache, 404s

Agreed with #17, marking this as duplicate of the other issue which has more information and patches.