Impossible to update cached script when transient already contains an incorrect value

[webaxones]

Describe the bug

I encountered this issue during the staging of a redesign:
The site was developed locally under Lando, in HTTPS, on a Bedrock architecture: redesign from a classic WC to a FSE WC, preserving the database.
So far, so good.

The site was then installed in staging, the database was imported and then adapted using wp db import and wp search replace.
The result: the blocks no longer worked.

The console indicated a mixed-content issue with the WC Blocks scripts related to the blocks on the page that were loaded in HTTP instead of HTTPS:
Specifically, on the home page with a customer account block, and a mini-cart block in the menu header: wc-settings.js, mini-cart-frontend.js, price-format.js (I'm not completely certain about the last one, but I am about the first two).
No other scripts from other plugins had this problem.

My staging, also using a Bedrock architecture, had in its .env its WP_ENV set to staging which defined SCRIPT_DEBUG to false. When I switched its WP_ENV to development which defined SCRIPT_DEBUG to true, the problem disappeared.

I have no idea why this transient has a URL in HTTP instead of HTTPS. A recording during an SSL certificate crash maybe? I don't know.
In any case, once recorded it cannot be updated.

After looking at the code, my first attempt was to delete all the transients via the WooCommerce tools. Negative.

My second attempt was to install the Transient Manager plugin to delete the transient woocommerce_blocks_asset_api_script_data. Negative.

The only thing that worked was to fix the values using a wp search-replace 'http:\/\/mystaging' 'https:\/\/mystaging'

I believe the problem comes from this commit
more specifically from this code

	public function update_script_data_cache() {
		if ( is_null( $this->script_data ) || $this->disable_cache ) {
			return;
		}
		set_transient(
			'woocommerce_blocks_asset_api_script_data',
			wp_json_encode(
				array(
					'script_data' => $this->script_data,
					'version'     => $this->package->get_version(),
				)
			),
			DAY_IN_SECONDS * 30
		);
	}

I am in the case where disable_cache is false:
If script_data is null, we don't update it
If script_data contains something (and in my case something wrong), we put its value back in the transient

I might be making a mistake in my analysis, or perhaps the problem is more complex, but in any case, the problem was definitely there :)

To reproduce

Steps to reproduce the behavior:

1. Modify the transient woocommerce_blocks_asset_api_script_data via PHPMyAdmin by replacing the HTTPS in the script wc-settings.js URL with HTTP
2. See the mixed-content problem on a page using WC Blocks
3. Attempt to delete the transient to fix the problem.

Environment

MacOS Ventura, Chrome...

WordPress (please complete the following information):

• WordPress version: 6.2.2
• WooCommerce version: 7.8.2
• WooCommerce Blocks version: 10.6.0

[opr]

@webaxones thanks for posting this, I was experiencing this issue too, but I experienced it when switching between the WooCommerce Feature plugin and the plugin bundled with WooCommerce core, which is something sites out in the wild could reasonably do.

Internal ref: p1689679862448749-slack-C02UBB1EPEF

I'll add this to our backlog to solve.

[kaushikasomaiya]

Just curious if the HTTP loading can break scripts from other plugins, merchant in 6566216-zen had issues loading WCPay dashboard when Woo Blocks was active;

Full Size: https://d.pr/i/e0GbL0

Edit: Able to replicate by modifying transient with HTTP value and going to WCPay > Deposits area. It breaks the script.

[opr]

Just curious if the HTTP loading can break scripts from other plugins, merchant in 6566216-zen had issues loading WCPay dashboard when Woo Blocks was active;

Looks like, since wc-settings isn't loading it's stopping other scripts working.