Instance update fails with Config manifest file does not exist: Plugins/ADSModule/DeploymentTemplates/–main/config.json after updating the source files on GitHub and fetching the repo again in AMP. Restarting the instance does not resolve it.
Repository GitHub - papiscze/omsi-multiplayer-amptemplate · GitHub (branch: main) Custom Generic Module templates for two dedicated server apps in the same repo (openOMSI, neoOMSI), following the standard AMPTemplates layout (manifest.json + flat template files in the repo root, no subdirectories). The config/metaconfig JSON files were drafted with Claude’s help (AI-assisted) and tested against the actual server binaries/generated server.cfg before use, per the AMPTemplates contribution guidelines - mentioning this in case it’s relevant to narrowing down the cause, though the file structure and JSON themselves validate fine and the same error occurs regardless of which file was last edited.
Error
Config manifest file does not exist:
Plugins/ADSModule/DeploymentTemplates/–main/openomsi-dedicated-serverconfig.json
Note the path: --main (empty-empty-main), not the expected – folder name (which on disk is papiscze-omsi-multiplayer-amptemplate-main, confirmed to exist via ls).
Steps to reproduce
Repo papiscze/omsi-multiplayer-amptemplate:main is already added as a Configuration Repository in AMP and has been fetched/used successfully before.
Push an update to the template files on GitHub (in this case: changes to *config.json and *metaconfig.json for the openomsi-dedicated-server app).
In AMP, go to Instance Deployment and fetch the repo again. The fetch itself succeeds (git log shows a clean fast-forward, no errors).
Attempt to update an existing instance running this template (e.g. via the instance’s Update button, or ampinstmgr).
The update fails with the --main path error above.
What we’ve confirmed
The fetch/pull step itself works correctly — AMP successfully pulls the latest commit from GitHub (verified via the ADS fetch log, clean fast-forward, no errors).
The files physically exist in the correct on-disk folder after fetch: …/DeploymentTemplates/papiscze-omsi-multiplayer-amptemplate-main/.
This is not limited to old/pre-existing instances: we previously reproduced the identical --main error on a brand-new instance created fresh from this template (not an upgrade of an older instance), which rules out a stale Meta.OriginalSource value as the sole cause.
Restarting the affected instance does not clear the error.
Before this round of file changes was pushed to GitHub, updating the same instances worked without this error.
What we haven’t been able to determine
Where exactly AMP derives the --main (empty user/repo) path from during the “refresh instance config after upgrade” step — it does not appear to come from the instance’s own Meta.OriginalSource (which is correct), so it looks like a separate internal lookup that isn’t resolving the repo name/owner correctly at that specific step.
Whether this is triggered specifically by updating files for an app that is not the first/primary one listed in the repo (this repo serves two apps from one manifest.json), or whether it’s unrelated to that.
Environment
AMP Generic Module, custom community template repo (not the official CubeCoders/AMPTemplates repo)
Linux, instances run under ADS01
AMP version: 2.8.0.8 - 20260927.1
