cypress: `blockHosts` test configuration override failing to apply

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:

blockHosts entry is added to the cypress.json configuration file as a string value (also tried an array with single string)
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:

config is set properly (confirmed the settings GUI)
logged the Cypress.config() value and confirmed that blockHosts is mutated to be an empty string
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

https://github.com/cbourdage/cypress-test-tiny/pull/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

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 8
Comments: 16 (4 by maintainers)

Most upvoted comments

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

cupcakepanda89 on Aug 10, 2022

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).

jennifer-shehane on Apr 20, 2022

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

JonathanSTH on Jan 5, 2024

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

rforster-dev on Feb 26, 2024

@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.

pgoforth on Apr 25, 2023