[Bug]: Stack configured icons missing in Unraid Dashboard Docker tile

[petecdk]

Version

compose.manager-2026.07.02-noarch-0825

Unraid Version

7.3.2

Bug Description

Summary:
Containers in a Compose stack that reference a local icon file via the net.unraid.docker.icon label never show their icon on the Unraid dashboard (Compose panel) — a broken-image / question-mark placeholder is shown instead. Server logs show the plugin requests a filename that is missing its last character, which causes a 404 against a file that actually exists. The Compose Manager Plus tile on the dashboard on the other hand shows icons correctly, so does the plugin itself within the stack configuration in Label section.

Related to issue #127 ?
Seems not to be related to #54

Note:
Hopefully not wasting your time; I just encountered 2 different logs within 1h distance, see below. So right now - after preparing this bug report - I am not so sure any more about the Off-by-one bug analysis. And no, I did not fiddle with the icon paths in the mean time ^^·
I will check back asap when I could hunt this down.

Expected Behavior

The dashboard Compose panel should display the configured icon whenever the net.unraid.docker.icon label points to a valid, readable local file path, matching the behavior already working correctly in the stack detail view.

Steps to Reproduce

1. Define a service in a Compose stack with a label pointing to a local file:

   labels:
     net.unraid.docker.icon: "/mnt/user/appdata/icons/example.png"

2. Bring the stack up and confirm the label is present on the running container:

   docker inspect <container_name> | grep -i icon

   Output:

   "net.unraid.docker.icon": "/mnt/user/appdata/icons/example.png",
   

3. Open the Unraid Dashboard → Docker Containers panel and observe the icon for this container/stack. It renders as a broken image / placeholder. The Compose Manager Plus panel shows the correct icons.

Evidence:

1. Plugin's internal representation (taken from Compose Manager log), icon field now wrapped with a file:// scheme:

[INFO] [refreshStackRow] response - Data:
{"project":"<project_name>","data":"{\"result\":\"success\",\"containers\":[{\"name\":\"<container_name>\", ...
\"icon\":\"file:\\/\\/\\/mnt\\/user\\/appdata\\/icons\\/example.png\", ...

2. Resulting browser request and nginx error, showing the filename truncated by exactly one character (example.pn instead of example.png):

nginx: [error] open()
"/usr/local/emhttp/mnt/user/appdata/icons/example.pn" failed
(2: No such file or directory) while sending to client, client: <redacted>,
request: "GET /mnt/user/appdata/icons/example.pn HTTP/1.1",
host: "<redacted>", referrer: "https://<redacted>/Compose"

Notes on this request:

• The only discrepancy between the requested path and the real file is the missing trailing g in the extension (.pn vs .png).

Relevant Logs

Jul 14 23:05:38 nginx: 2026/07/14 23:05:38 [error] 29065#29065: *103241 open() "/usr/local/emhttp/mnt/user/appdata/icons/example.pn" failed (2: No such file or directory) while sending to client, client: <redacted>, server: , request: "GET /mnt/user/appdata/icons/example.pn HTTP/1.1", host: "<redacted>", referrer: "https://<redacted>/Compose"

Jul 15 00:14:24 nginx: 2026/07/15 00:14:24 [error] 29065#29065: *114127 "/usr/local/emhttp/mnt/user/appdata/icons/example.png/index.html" is not found (20: Not a directory) while sending to client, client: <redacted>, server: , request: "GET /mnt/user/appdata/icons/example.png/ HTTP/1.1", host: "<redacted>", referrer: "https://<redacted>/Compose"

Compose

Additional Context

Suspected Root Cause: Off-by-one
It looks like the plugin internally wraps a local icon path with a file:// scheme, then strips that scheme again when constructing the browser-facing image URL. That strip step appears to drop one extra character from the end of the string — consistent with logic originally intended to remove a trailing character.

[mrunknownpbu]

I believe I've found an additional issue that may be related, but it appears to occur before the dashboard rendering stage.

Environment
Unraid 7.x
Compose Manager Plus 2026.07.02-noarch-0825
Stack using External Compose Folder (/mnt/user/appdata/compose)
Investigation

The service metadata is correctly stored in containers.cache.json.

For example:

"komga": {
"icon": "https://cdn.jsdelivr.net/gh/selfhst/icons/png/komga.png",
"webUI": "http://10.1.10.200:25600"
}

However, the generated:

/boot/config/plugins/compose.manager/projects/docker-compose/compose.override.yaml

contains:

komga:
labels:
net.unraid.docker.icon: ''
net.unraid.docker.webui: ''

while another service in the same stack (e.g. prowlarr) is generated correctly:

prowlarr:
labels:
net.unraid.docker.icon: 'https://cdn.jsdelivr.net/gh/selfhst/icons/png/prowlarr.png'
net.unraid.docker.webui: 'http://10.1.10.200:9696'
Additional Findings

The cache contains the correct values:

jq '.["docker-compose"].komga | {icon, webUI}'
/boot/config/plugins/compose.manager/containers.cache.json

Output:

{
"icon": "https://cdn.jsdelivr.net/gh/selfhst/icons/png/komga.png",
"webUI": "http://10.1.10.200:25600"
}

But the generated compose.override.yaml still contains blank values.

This suggests the metadata is successfully saved into containers.cache.json, but the override generation step is not consistently copying the values into compose.override.yaml.