blockHosts test configuration override failing to apply

[cbourdage]

Current behavior

Hello, I've been troubleshooting some strange behavior when leveraging the blockHosts configuration value and overriding the value with the Test Specific Configuration options.

Steps/setup:

1. blockHosts entry is added to the cypress.json configuration file as a string value (also tried an array with single string)
2. added an override for a test suite to set the blockHosts entry to null (the default) describe('my suite', {blockHosts: null}, () => {});

Current setup:

// cypress.json
{ "blockHosts": "*.pendo.io" }

// integration/my-suite.test.js
describe('my suite', {blockHosts: ''}, () => {});

The specific my suite test suite continues to block requests to pendo.io.

What I've identified thus far:

1. config is set properly (confirmed the settings GUI)
2. logged the Cypress.config() value and confirmed that blockHosts is mutated to be an empty string
3. The x-cypress-matched-blocked-host gets set with the original blockHosts value

I have tried with various different values for the blockHosts and also tried using the Cypress.config API directly but experienced the same behavior. From my understanding the blockHosts configuration value is not one of the read only configuration options.

Desired behavior

When providing blockHosts as a configuration value for a test suite, it should override the current blockHosts value and the cypress test should respect the new blockHosts value. This same override should be applicable using Cypress.config('blockHosts', '')

Test code to reproduce

cbourdage/cypress-test-tiny#1

I have been able to replicate this in 2 repos now so you should be able to use any existing tests to try to override the blockHosts configuration option.

Cypress Version

9.3.1

Other

No response

[jennifer-shehane]

blockHosts should override the config via a test config override. Looks like a bug. I'm not sure that we have tests for this internally (couldn't find them quickly).

[Joelasaur]

I can confirm I'm seeing the exact same issue. We found a bug in our app that requires us to test the adblocker user experience, and configuring blockHosts works great for this usecase - except we don't want to set this blockHosts value globally. Right now to solve this we would have to configure two separate json files to be passed in to two different cypress run commands with the --config-file flag, just to support this one test. We'd rather not have to upend our CI yaml for this single test but would like the coverage. Looking forward to a fix and/or workaround.

[njday]

Im having the same problem with this on v9.7.0

Is there any update on this issue?

[cupcakepanda89]

I'm on v10.4.0 and have similar issue, blockHosts seems not working correctly.

[GregoryVds]

I am on v.10.8.0 and I can confirm this issue is still present as well 😞

[ecclesm]

Seeing this issue in v9.6.0

[kamilmoskal]

bump

[jeroenburgers]

This is still an issue in 11.2.0. I was hoping it was fixed by #24257, but that was only for the default config. When you override the blockHosts in your test, there is nothing happened.

[pgoforth]

Seems that the config options never take because blockHosts is in the server context config....which is static unless the server restarts. Ergo, the server restart is never triggering, or the config in the context is never being updated between tests.

[emilyrohrbough]

@pgoforth You are correct - this seems to be incorrectly marked as a configuration that can be override at the test/suite level but its updated value will not take effect if updated at run-time. The bug here seems to be that this was incorrectly flagged as configurable at the test/suite level.

[pgoforth]

@emilyrohrbough It's one thing to fix the documentation to align with functionality, but it would seem that any config parameter used inside packages/proxy would not be able to be changed at test time. The feature I'm working on (although would not require it) would greatly benefit from having test/suite level config updates inside packages/proxy. Is there a current methodology that can be used to achieve this? Is there an outstanding feature request for it? Either way, I feel compelled to work on it (since it would expedite my feature) and would like to make sure I am attacking the problem from the proper vector.

[JonathanSTH]

@emilyrohrbough @jennifer-shehane @brian-mann any word on this?

[cupcakepanda89]

any update on this issue

[rforster-dev]

Any update on this? Keen to use this functionality instead of having to create a separate config file for a select number of spec files that need to have an alternative list of blockHosts!

[rforster-dev]

If anyone is reading this, and wondering how i've overcome this...

// cypress/support/blockHosts.js

const defaultBlockHosts = [
  //default array of regex urls to ignore
  '*google-analytics.com*',
];

const alternativeBlockHosts = [
  //alternative array of regex urls to ignore
  '*google-analytics.com*',
  ...
];

export const blockUrls = (useAlternative = false) => {
  const blockHosts = useAlternative ? alternativeBlockHosts : defaultBlockHosts;

  blockHosts.forEach((host) => {
    // Intercept each entry and block the URL
    cy.intercept(host, (req) => {
      req.destroy();
    });
  });
};

// cypress/support/index.js
`const shouldIgnoreSpec = (specFileName) => {
  // Specify the folder pattern to ignore
  const patternToIgnore = /path/to/ignore/;

  // Check if the spec file name matches the pattern to use the refined/lite list
  return patternToIgnore.test(specFileName);
};

beforeEach(() => {
  const specFileName = Cypress.spec.relative;

  if (shouldIgnoreSpec(specFileName)) {
    blockUrls(true); // Use the default block hosts
    return;
  }
  blockUrls();
});

So in this example what i'm doing is, i'm setting up two arrays of URLs to block. There is a default list, and then a lite list.

Before every spec is ran, if the spec file is within the folder in the pattern, it will use the refined list, otherwise, it will block the requests by default.

This is a bit messy, but should be sufficient until this is resolved. I want to point out as well that in the docs it clearly states that blockHosts is able to be overriden

https://docs.cypress.io/guides/references/configuration#Test-Configuration

[JonathanSTH]

Will give this a shot in the near future. Thanks for the assistance.

[XavierDupessey]

Hello! Any news about this feature? Thanks :)

[XavierDupessey]

@rforster-dev unfortunately, the code you shared does not work for all cases, e.g. requests initiated by <script> tags

[jennifer-shehane]

Just ran into this issue myself with the cypress-documentation repo. I want to test the cookie consent dialog in one test, but blog it from opening in all other tests.

  blockHosts: ['cmp.osano.com'],

  it.only('should close cookie consent dialog', { blockHosts: null }, () => {
    cy.get('.osano-cm-dialog__close').should('be.visible').click()
    cy.get('.osano-cm-dialog__close').should('not.be.visible')
  })