[Bug]: Creating new stack with indirect folder does not create compose.override file

[FudiHub]

Version

2026.07.02

Unraid Version

7.3.1

Bug Description

Creating a new stack with an external / indirect folder path (e.g. /mnt/user/appdata/newstack) does not create the compose.override.yaml under /boot/config/plugins/compose.manager/projects/newstack
This results in an error when the compose.sh script tries to autostart the stack. Because the script is expecting the override file to be present the stack can not start.

Expected Behavior

The compose.override.yaml file should be created when the stack is created with indirect folder.

Steps to Reproduce

• make a new stack folder "newstack" under /mnt/user/appdata/
• Create an new Stack with the compose plugin (gui)
• Select the path /mnt/user/appdata/newstack as indirect folder path for the project
• ls /boot/config/plugins/compose.manager/projects/newstack -> compose.override.yaml is missing

Relevant Logs

-

Compose

-

Additional Context

Suggested fix:
Make sure the compose.override file is beeing created under the project path of the compose plugin

[TicketWindowSeat]

The fix addresses the creation-time case: StackInfo::createNew() now writes the app-managed override template for newly created stacks. It does not cover stacks created before this change, or cases where that override is subsequently absent.

There is also an inconsistency between the two explicit-mode argument representations returned by StackInfo::buildComposeArgs(). The string generated by buildComposeFileFlags() emits a -f argument only when is_file($filePath) is true, whereas filePaths receives getComposeFilePaths() without that same final existence check. ComposeCommandBuilder::buildForAction() publishes filePaths as composeFiles; the shell action-spec loader preserves every entry, and stopping_docker converts each one into an explicit -f argument.

Consequently, a computed-but-absent project override can still reach Docker Compose in explicit mode.

Would you consider either:

1. Excluding a nonexistent computed project override from the action-spec composeFiles, preferably with a warning while preserving errors for explicitly user-configured files; or
2. Adding a one-time upgrade migration that creates the app-managed override template for existing stacks?

A regression test in ComposeCommandBuilderTest using an existing stack with a main compose file but no project override could assert that the resulting action specification contains no nonexistent override path. That would guard the shared contract consumed by both autostart and shutdown handlers.