[Icons] ux:icon:warm-cache interprets close:prevent (a live_action) as an icon during warmup, causing failure

[jvancoillie]

Summary

Error during the ux:icon:warm-cache process when encountering live_action('close:prevent') in a UX Live Component. The issue occurs in environments where access to Iconify is blocked or misconfigured, such as in a CI pipeline or local development setup.

Description

When using the live_action function in a UX Live Component, such as:

<a href="#" {{ live_action('close:prevent') }} >Close</a>

The warmup process attempts to resolve an icon named prevent from the close collection. This causes a failure because close:prevent is not an icon definition but a Live Action attribute.

The issue was initially discovered in a CI pipeline behind a proxy that blocks access to Iconify, but it can also be reproduced in a local development environment with restricted access to the Iconify endpoint.

Steps to Reproduce

1. Add a live_action('close:prevent') call in a UX Live Component.
2. Test in an environment with one of the following conditions:
   • A CI pipeline behind a proxy that blocks access to Iconify.
   • A local development environment where access to the Iconify endpoint is restricted or misconfigured.
3. Run the warmup process.
4. Observe the error.

Expected Behavior

The warmup process should ignore or properly handle live_action calls, ensuring they are not mistakenly interpreted as icon definitions. Additionally, it should handle restricted or misconfigured network environments gracefully.

Actual Behavior

The process attempts to resolve prevent as an icon from the close collection. In environments where Iconify is inaccessible or misconfigured, this results in a failure during warmup.

[smnandre]

Could you give us some details regarding the error ? What exception do you get ? With what message / output in the console ?

[jvancoillie]

Indeed, I forgot to share detailed information about the error encountered.

In my CI environment, I occasionally run into this error when I haven't locked the icons using the ux:icons:lock command. Normally, this issue is quickly resolved by providing the necessary icons. However, this time, the problem is different: it attempts to retrieve an icon that isn't actually an icon.

The close:prevent value is used in a live_action and will never be an icon. As a result, I cannot resolve this issue by providing an SVG, as the icon simply doesn't exist.

Here are the logs from my CI environment:

// ...
Executing script cache:clear [OK]
Executing script assets:install public [OK]
Executing script importmap:install [OK]
$ php bin/console asset-map:compile
Warming the icon cache...
In TraceableResponse.php line 209:
                                                                               
  HTTP/1.1 403 Forbidden returned for "https://api.iconify.design/collections  
  ".                                                                           
                                                                               
In ErrorChunk.php line 73:
                                                                               
  Received HTTP code 403 from proxy after CONNECT for "https://api.iconify.de  
  sign/collections".                                                           
                                                                               
In CurlResponse.php line 319:
                                                                               
  Received HTTP code 403 from proxy after CONNECT for "https://api.iconify.de  
  sign/collections".                                                           
                                                                               
asset-map:compile
Cleaning up project directory and file based variables 00:01
ERROR: Job failed: command terminated with exit code 1

To further illustrate the issue, I also ran the ux:icons:warm-cache command on my local development environment in verbose mode (-vvv). Below are the logs showing the API call made for close:prevent:

root@701a9d281dd1:/srv/app# bin/console ux:icons:warm-cache -vvv

 // Warming the icon cache...

07:00:57 INFO      [cache] Lock acquired, now computing item "close--prevent"
[  "key" => "close--prevent"]
07:00:57 INFO      [http_client] Request: "GET https://api.iconify.design/collections"
07:00:57 INFO      [http_client] Response: "200 https://api.iconify.design/collections" 0.101043 seconds
[  "http_code" => 200,  "url" => "https://api.iconify.design/collections",  "total_time" => 0.101043]
//...

As shown, the warmup process tries to compute close--prevent and makes an API call to retrieve icon data, even though close:prevent is not an icon but part of a live_action.

To summarize, the issue arises because close:prevent is mistakenly interpreted as an icon, triggering a request to the Iconify API. This request fails in my CI environment due to a blocked connection.

[smnandre]

To summarize, the issue arises because close:prevent is mistakenly interpreted as an icon, triggering a request to the Iconify API. This request fails in my CI environment due to a blocked connection.

This is not a problem most of the time, as the prefix is checked before trying a particular icon, against the list of collection prefixes.

But in your case, the list of collection prefixes does not exist and is "fetched" from iconify, making the whole thing crash because Iconify is not reachable.

To be sure, iconify is disabled in this environment ? (php bin/console debug:config ux_icons)

[jvancoillie]

You're absolutely right. Iconify wasn't disabled in the production environment during the Docker image build. I initially thought it could be useful, but since I'm locking the icons, enabling Iconify in production is unnecessary.

I'll configure Iconify to be enabled only in the development environment for locking icons and disable it in all other environments. This resolves the issue, it wasn't a bug but rather a misunderstanding on my part.

Apologies for the inconvenience, and thank you for pointing this out!