502 Bad Gateway on Frontend After Update to beta 3 (from 2)

https://www.drupal.org/project/domain/issues/3539748 🐛 Internal Server Error when editing/viewing nodes after PHP upgrade Active

Can you check if the error disappears if you modify the files as a test? I had a similar problem.

I'm not sure what should be done here.

May be you should stick to 2.0.0-beta2 for now.

I'm leaving this open in case other people have encountered the same problem.

This is also affecting us, but locally during development.

In our local logs we found:

NGINX Error: Upstream sent too big header while reading response header from upstream

Further debugging found that one developer altered http.response.debug_cacheability_headers in development.services.yml from true to false, but another developer had to completely disable development.services.yml</code in <code>settings.local.php for these 502 errors to disappear.

Hope this may aid finding where the actual problem lies

@intrafusion, have you tried increasing NGINX proxy_buffer_size setting?

Did you notice any change in your page http headers between 2.0.0-beta2 and 2.0.0-beta3?

Hi team,
To provide some additional context, while investigating an issue, I discovered that the method \Drupal\domain_config\DomainConfigOverrider::getCacheableMetadata is adding cache tags for all possible configurations at the line:

$metadata->addCacheTags(['config:' . $config_name['domain'], 'config:' . $config_name['langcode']]);

When this line is enabled, it generates cache tags for every potential site configuration. For example:

{
  "langcode": "domain.config.gb.en.field.storage.paragraph.field_horizontal_position",
  "domain": "domain.config.gb.field.storage.paragraph.field_horizontal_position"
}

If I comment out this line, the site returns to normal performance. With logging enabled, I can confirm that the code is producing an excessive number of cache tags, which appears to be the cause of the issue.

In short, this use of `addCacheTags` is leading to performance problems by tagging every possible config, rather than only the relevant ones.

Hope this gives some clues

P.S. our site is huge and has vast amount of configs

Thanks @povilas-uogintas for the hint, I'll have a look a it.

Hi @mabli,

At the moment, until I fully understand the rationale why this has been added to ALL configs (or to very, very many of them), my initial thing will be either:

1. To turn off completely, aka uncomment it out // probably not the best approach
2. Add another config form where specific configs can be selected to which these cacheTags will need to be added.

Do you think this makes sense?

I think the cache tags should only be added to the overridden configs.

I'll work on a patch on the original issue.

@povilas-uogintas could you give a try to the following MR and see if it fixes your problem? Thanks.

https://git.drupalcode.org/project/domain/-/merge_requests/161

Hi @mably,

I have just applied the patch and everything seems to be working.

Many thanks!

I'll add a small test and merge it. Thanks for the review!

Fix has been merged to 2.0.x-dev branch.

@intrafusion @bruno2 could you give it a try and see if it solves your problem?

And @summerg too.

I've given you a rewrite to clean up the code, and here are the differences from the current file. I found an older version (https://github.com/agentrickard/domain/blob/8.x-1.x/domain_config/src/Do...) that's readable, but this file is a mess, sorry!

Cleaner code:
- readable
- better error handling with try/catch,
- better cache cleanup and memory manage

Better performance:
- it loads multiple the configs, instead one by one
- fewer database calls
- avoid memory leaks

Disabling the cache tag does not fix the other problems.

@bruno2 not sure to understand what you are talking about.

Are you saying that 502 errors are still present with latest 2.0.x-dev?

Thats not the point. I told you these small fix can not solve the whole errors with this file! It's trash and needs to be cleaned up, especially because it's loaded so frequently.

Look for these bad pattern:
\Drupal::languageManager(); // Bad - should not loaded directly, only if needed.
\Drupal::service('domain.negotiator'); // Bad - hard to test

Other Problems:
- Loads configs one at a time (slow)
- No proper cache cleanup
- Static variables that can cause memory leaks -> line 122 static $lookups; // will not cleared and can be growing endless
- Hard to Read // Complex nested if/else statements

I'm closing this as fixed for now.

@bruno2 feel free to open new dedicated issues for the other points you mention.

And provide complete and documented MRs that pass all the module's tests (or adapt them accordingly).

Ran into this issue as well after updating to beta3. The issue was fixed in the -dev version, but the change to does apply cleanly as a patch

#3538150-18: 502 Bad Gateway on Frontend After Update to beta 3 (from 2) → mentions

And if everything is ok, I'll publish a 2.0.0-beta4 release.

A new beta version should prevent other sites from running into this issue, so a new release tag would be very welcome

Hi @idebr, it's definitely on my todo list.

Just trying to include a few more issues before releasing beta4.