Problem/Motivation

Trying to explain the increase in random JS testing fails and we're wondering if DNS resolution is the cause again.

Apparently we've seen a massive increase in the DNS requests to drupal.org since switching to gitlabci. Maybe this is caused by Chrome doing DNS prefetching - see https://www.chromium.org/developers/design-documents/dns-prefetching/

We can disable this in chromedriver so let's see if that makes a difference.

The 'powered by Drupal' block links to Drupal.org, so it is possible that DNS for this link is being prefetched.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3402061

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

alexpott created an issue. See original summary.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Status: Active » Needs review

catch opened merge request !5425

fjgarlin’s picture

fjgarlin commented

The code looks good, just wonder about all those many other random failures in the pipelines that were triggered manually. I guess re-running them would fix the issue.

smustgrave made their first commit to this issue’s fork.

smustgrave’s picture

smustgrave commented

So I rebased and got another random failure so maybe this isn't the culprit?

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

Reran the tests multiple times but still got random failures, sending back to NW to figure out what can be tried next.

fjgarlin’s picture

fjgarlin commented
Status: Needs work » Needs review

I wonder if some of those failures come from this other #3316274: Stabilize FunctionalJavascript testing AJAX: add ::assertExpectedAjaxRequest() issue as the comment made here https://www.drupal.org/project/drupal/issues/3316274#comment-15325057 (which I also ran into in another issue).

I don't think the code of this MR needs further changes. This MR is about the the d.org requests made from the tests, not random failures, so I'll marked it as "Need review" (was tempted to even RTBC) again as I managed to get a full green pipeline: https://git.drupalcode.org/issue/drupal-3402061/-/pipelines/51705

I think the only way to actually test this is to merge and see if the overall requests to d.org go down.

smustgrave’s picture

smustgrave commented
Status: Needs review » Reviewed & tested by the community

If we want to add this sure, only moved to NW as it didn't seem to impact the random javascript errors. But if it could help other stuff.

fjgarlin’s picture

fjgarlin commented
Component: other » phpunit

Changing component to phpunit and also rebased the MR to make sure it's up to date with latest changes.

catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Needs review

This turned out to not be the cause of random test failures, although we still have unexplained/unaccounted for additional DNS requests to Drupal.org, should we do it anyway or just leave it?

fjgarlin’s picture

fjgarlin commented

I think it’s worth trying if it means less unnecessary requests to drupal.org

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

https://www.chromium.org/developers/design-documents/dns-prefetching/

Chromium uses the "href" attribute of hyperlinks to find host names to prefetch.

So unless we have <a href> tags (or <link rel="dns-prefetch">) linking to drupal.org in tests, I don't think this can be the source of the problem.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs review » Reviewed & tested by the community

Oh! The "Powered by Drupal" block *does* link to drupal.org. So maybe there is something in this?

catch’s picture

catch
he/him
Primary language English
commented
Issue summary: View changes
Status: Reviewed & tested by the community » Needs work

Doh we even talked about this on slack weeks/months ago I think.

Updated the issue summary to note that, but this needs a rebase now.

fjgarlin’s picture

fjgarlin commented
Status: Needs work » Reviewed & tested by the community

Rebased. Back to RTBC.

I was bitten by #3401988: Spell-checking job fails with "Argument list too long" when too many files are changed, but updating the 11.x branch of the fork and rebasing fixed it for now.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Version: 11.x-dev » 10.2.x-dev
Status: Reviewed & tested by the community » Fixed

Backported to 10.2.x because if we are going to see a difference it will be easier when it's on more branches.

Committed and pushed 14ab34aaad to 11.x and 791cf59ae4 to 10.2.x. Thanks!

  • longwave committed 791cf59a on 10.2.x 
    Issue #3402061 by fjgarlin, alexpott, smustgrave, catch, longwave:...

  • longwave committed 14ab34aa on 11.x 
    Issue #3402061 by fjgarlin, alexpott, smustgrave, catch, longwave:...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.