Olares 1.12.6: Studio dev apps can no longer be installed — Source data not found, and no Studio version is compatible with 1.12.6
Summary
After upgrading to Olares 1.12.6, no application developed in Studio can be installed or re-applied any more. Clicking Apply on an existing dev app uninstalls it and then fails to reinstall, leaving the app permanently down.
The root cause appears to be that the 1.12.6 chart-repository migration upgrade-1126-remove-studio-source removes the chart source named studio, while the installed studio-server still queries the repository with Source: studio. In addition, the Studio app itself declares Compatibility: Olares >=1.12.3-0,<1.12.6, so there is currently no Studio release that is compatible with 1.12.6 and the Market offers no update.
Recovering the app was possible only by hand-migrating the chart to manifest v3 and uploading it as a custom package — which in turn detached the app's persistent appdata directory (see Secondary issue).
Environment
| Component |
Version |
| Olares |
1.12.6 |
| Studio (app / chart) |
installed 1.0.48, latest in Market 1.0.51 |
| studio-server |
beclab/studio-server:v0.1.73 |
| dynamic-chart-repository |
beclab/dynamic-chart-repository:v0.3.49 |
| app-service |
beclab/app-service:0.5.67 |
| Node |
single node, amd64 |
The affected app is a plain Deployment + Service created in Studio from a Docker image. It had been installed and re-applied many times without problems before the 1.12.6 upgrade.
Steps to reproduce
- Run Olares 1.12.6 with an app that was created in Studio before the upgrade.
- Open the app in Studio and click Apply (for example after changing the container image tag).
- Studio uninstalls the running app, then fails with:
check chart version failed: Source data not found
- The app is now uninstalled and cannot be reinstalled. Reverting the image tag, bumping the chart version, restarting Studio and restarting the node all produce the identical error.
Evidence from the logs
studio-server — the chart upload itself succeeds; the follow-up version query fails:
handlers_cmd.go:327 auto update repo, name claudebot
updaterepo.go:44 start to upgrade chart version app=claudebot
updaterepo.go:54 uploadChartVersion to 0.0.33
command.go:26 command output:
Pushing claudebot-dev-0.0.33.tgz to http://localhost:8888...
Done.
updaterepo.go:147 update repo app claudebot, newVersion: 0.0.33
chart_op.go:108 /api/v1/charts/Source data not found
/versions status code not = 200, err=%!v(MISSING)
(Note the broken format string on the last line — err is never passed, so the real error is lost.)
chartrepo — the query arrives with Source: studio:
service.go:25 User Context - UserID: <user>, Source: studio
service.go:41 User Action - UserID: <user>, Source: studio, Action: GET_VERSIONS, Resource: claudebot-dev
chartrepo, at startup — the studio source has been removed by the 1.12.6 migration:
upversion_1126.go:133 upgrade-1126-remove-studio-source: migration already completed, skipping
upversion_1126.go:133 upgrade-v3-catalog-layout: migration already completed, skipping
chartrepo — meanwhile the same app resolves fine under the upload source:
app_data.go:319 Searching for app: claudebot-dev in source: upload
app_data.go:356 Found app: claudebot-dev in source: upload
So Source data not found is literal: the source named studio no longer exists. studio-server v0.1.73 has not been updated to query upload.
The compatibility dead end
Because Studio's own install path is broken, the remaining route is the Market's custom-package upload. That path is blocked by a contradiction:
Uploading a v1 manifest is rejected unless the system dependency is narrowed:
manifest validation failed (apiVersion=v1):
options.dependencies[name=olares].version ">=1.12.1-0" must restrict the Olares system
version to ">=1.12.3-0,<1.12.6" for apiVersion=v1; the constraint currently allows 1.12.6,
which is outside the supported range
Installing the resulting package is then rejected because the running system is 1.12.6:
Missing dependencies: System Dependencies: - olares version=>=1.12.3-0,<1.12.6
No version range can satisfy both: the validator requires an upper bound of <1.12.6, and the installer requires the range to include the running 1.12.6. v1 applications are therefore uninstallable on 1.12.6 by construction.
The same bound applies to Studio itself. The Market shows:
Studio — Chart version 1.0.51 — Compatibility: Olares >=1.12.3-0, <1.12.6
There is no update offered, and the newest published Studio declares itself incompatible with 1.12.6.
Additional finding: Studio-generated names cannot pass the new validator
Studio names every dev app <name>-dev. Installing such an app through the Market's custom-package route fails on the new folder-name rule:
invalid folder name: "./charts/claudebot-dev" must match ^[a-z0-9]{1,30}$
A hyphen is not allowed, so no Studio-generated app name can ever satisfy this validator. This forces users to rename the app, which has the consequence described below.
Secondary issue: renaming an app detaches its appdata
Charts generated by Studio mount persistent data via:
volumes:
- hostPath:
path: "{{ .Values.userspace.appData }}/<appname>/"
type: DirectoryOrCreate
.Values.userspace.appData is derived from the application name. Renaming the app (which the folder-name rule above makes mandatory) silently changes the resolved path — in this case from …/claudebot-dev/claudebot/ to …/claudebot/claudebot/.
The app then starts successfully against an empty directory. /health reports the data directory as existing, the container comes up, and nothing signals that the previous data is not attached. In this case the application's file-sync process started against an empty source directory; only its own delete-protection prevented the remote copy from being emptied.
Suggestion: when an app is installed with permission.appData: true and the resolved appdata directory is newly created while a directory for a previous name still exists, warn the user, or offer to carry the data over.
Workaround
For the record, this sequence restored the app on 1.12.6, without Studio:
- Take the chart from the Studio project (
Chart.yaml, OlaresManifest.yaml, values.yaml, templates/).
- Rename the chart directory to a name matching
^[a-z0-9]{1,30}$.
- Migrate
OlaresManifest.yaml to manifest 0.12.0 / apiVersion: v3: add apiVersion, add workloadReplicas, remove metadata.appid and metadata.target, set permission.appCommon/externalData explicitly, use the _v112 category names, and set the dependency to olares >=1.12.6-0.
- In
templates/deployment.yaml, set strategy: {type: Recreate} — required because the chart mounts a hostPath:
deployment <name> can not enable rolling update with hostpath
- Define
workloads.<name>.replicaCount in values.yaml and reference it from spec.replicas:
templates/deployment.yaml: spec.replicas is set to "1"; it must reference .Values.workloads.<name>.replicaCount
- Package as
.tgz and install through the Market's custom-package upload.
- Move the old
appdata directory to the new app name (see above).
Each of these five validation errors was clear and actionable — that part of the new validator works well. The problem is that Studio produces packages that cannot pass it, and offers no migration path.
Suggested fixes
- Ship a Studio release compatible with 1.12.6 that queries the
upload source instead of the removed studio source, and publish it before or together with the platform upgrade.
- Have
upgrade-1126-remove-studio-source either keep a compatibility alias for studio, or block/warn on upgrading while an incompatible studio-server is installed.
- Do not let Apply uninstall the running app before the reinstall has been validated. Currently a failed validation leaves a previously working app permanently down — that is the difference between an error message and an outage.
- Fix the format string at
chart_op.go:108; the underlying error is currently discarded (err=%!v(MISSING)), which makes this class of failure much harder to diagnose than it needs to be.
- Allow the
-dev suffix that Studio itself generates, or migrate existing dev app names automatically.
- Warn when a rename would detach an existing
appdata directory.
Impact
On a single-user system this took a production application offline for several hours and required hand-editing chart internals to recover. Anyone running a self-built app from Studio will hit this the first time they click Apply after upgrading to 1.12.6, and the app will stay down until they do the same manual migration.
(The username in the log excerpts has been replaced with <user>.)
# Olares 1.12.6: Studio dev apps can no longer be installed — `Source data not found`, and no Studio version is compatible with 1.12.6
Summary
After upgrading to Olares 1.12.6, no application developed in Studio can be installed or re-applied any more. Clicking Apply on an existing dev app uninstalls it and then fails to reinstall, leaving the app permanently down.
The root cause appears to be that the 1.12.6 chart-repository migration upgrade-1126-remove-studio-source removes the chart source named studio, while the installed studio-server still queries the repository with Source: studio. In addition, the Studio app itself declares Compatibility: Olares >=1.12.3-0,<1.12.6, so there is currently no Studio release that is compatible with 1.12.6 and the Market offers no update.
Recovering the app was possible only by hand-migrating the chart to manifest v3 and uploading it as a custom package — which in turn detached the app's persistent appdata directory (see [Secondary issue](#secondary-issue-renaming-an-app-detaches-its-appdata)).
Environment
| Component |
Version |
| Olares |
1.12.6 |
| Studio (app / chart) |
installed 1.0.48, latest in Market 1.0.51 |
studio-server |
beclab/studio-server:v0.1.73 |
dynamic-chart-repository |
beclab/dynamic-chart-repository:v0.3.49 |
app-service |
beclab/app-service:0.5.67 |
| Node |
single node, amd64 |
The affected app is a plain Deployment + Service created in Studio from a Docker image. It had been installed and re-applied many times without problems before the 1.12.6 upgrade.
Steps to reproduce
- Run Olares 1.12.6 with an app that was created in Studio before the upgrade.
- Open the app in Studio and click Apply (for example after changing the container image tag).
- Studio uninstalls the running app, then fails with:
check chart version failed: Source data not found
- The app is now uninstalled and cannot be reinstalled. Reverting the image tag, bumping the chart version, restarting Studio and restarting the node all produce the identical error.
Evidence from the logs
studio-server — the chart upload itself succeeds; the follow-up version query fails:
handlers_cmd.go:327 auto update repo, name claudebot
updaterepo.go:44 start to upgrade chart version app=claudebot
updaterepo.go:54 uploadChartVersion to 0.0.33
command.go:26 command output:
Pushing claudebot-dev-0.0.33.tgz to http://localhost:8888...
Done.
updaterepo.go:147 update repo app claudebot, newVersion: 0.0.33
chart_op.go:108 /api/v1/charts/Source data not found
/versions status code not = 200, err=%!v(MISSING)
(Note the broken format string on the last line — err is never passed, so the real error is lost.)
chartrepo — the query arrives with Source: studio:
service.go:25 User Context - UserID: <user>, Source: studio
service.go:41 User Action - UserID: <user>, Source: studio, Action: GET_VERSIONS, Resource: claudebot-dev
chartrepo, at startup — the studio source has been removed by the 1.12.6 migration:
upversion_1126.go:133 upgrade-1126-remove-studio-source: migration already completed, skipping
upversion_1126.go:133 upgrade-v3-catalog-layout: migration already completed, skipping
chartrepo — meanwhile the same app resolves fine under the upload source:
app_data.go:319 Searching for app: claudebot-dev in source: upload
app_data.go:356 Found app: claudebot-dev in source: upload
So Source data not found is literal: the source named studio no longer exists. studio-server v0.1.73 has not been updated to query upload.
The compatibility dead end
Because Studio's own install path is broken, the remaining route is the Market's custom-package upload. That path is blocked by a contradiction:
Uploading a v1 manifest is rejected unless the system dependency is narrowed:
manifest validation failed (apiVersion=v1):
options.dependencies[name=olares].version ">=1.12.1-0" must restrict the Olares system
version to ">=1.12.3-0,<1.12.6" for apiVersion=v1; the constraint currently allows 1.12.6,
which is outside the supported range
Installing the resulting package is then rejected because the running system is 1.12.6:
Missing dependencies: System Dependencies: - olares version=>=1.12.3-0,<1.12.6
No version range can satisfy both: the validator requires an upper bound of <1.12.6, and the installer requires the range to include the running 1.12.6. v1 applications are therefore uninstallable on 1.12.6 by construction.
The same bound applies to Studio itself. The Market shows:
Studio — Chart version 1.0.51 — Compatibility: Olares >=1.12.3-0, <1.12.6
There is no update offered, and the newest published Studio declares itself incompatible with 1.12.6.
Additional finding: Studio-generated names cannot pass the new validator
Studio names every dev app <name>-dev. Installing such an app through the Market's custom-package route fails on the new folder-name rule:
invalid folder name: "./charts/claudebot-dev" must match ^[a-z0-9]{1,30}$
A hyphen is not allowed, so no Studio-generated app name can ever satisfy this validator. This forces users to rename the app, which has the consequence described below.
Secondary issue: renaming an app detaches its appdata
Charts generated by Studio mount persistent data via:
volumes:
- hostPath:
path: "{{ .Values.userspace.appData }}/<appname>/"
type: DirectoryOrCreate.Values.userspace.appData is derived from the application name. Renaming the app (which the folder-name rule above makes mandatory) silently changes the resolved path — in this case from …/claudebot-dev/claudebot/ to …/claudebot/claudebot/.
The app then starts successfully against an empty directory. /health reports the data directory as existing, the container comes up, and nothing signals that the previous data is not attached. In this case the application's file-sync process started against an empty source directory; only its own delete-protection prevented the remote copy from being emptied.
Suggestion: when an app is installed with permission.appData: true and the resolved appdata directory is newly created while a directory for a previous name still exists, warn the user, or offer to carry the data over.
Workaround
For the record, this sequence restored the app on 1.12.6, without Studio:
- Take the chart from the Studio project (
Chart.yaml, OlaresManifest.yaml, values.yaml, templates/).
- Rename the chart directory to a name matching
^[a-z0-9]{1,30}$.
- Migrate
OlaresManifest.yaml to manifest 0.12.0 / apiVersion: v3: add apiVersion, add workloadReplicas, remove metadata.appid and metadata.target, set permission.appCommon/externalData explicitly, use the _v112 category names, and set the dependency to olares >=1.12.6-0.
- In
templates/deployment.yaml, set strategy: {type: Recreate} — required because the chart mounts a hostPath:
deployment <name> can not enable rolling update with hostpath
- Define
workloads.<name>.replicaCount in values.yaml and reference it from spec.replicas:
templates/deployment.yaml: spec.replicas is set to "1"; it must reference .Values.workloads.<name>.replicaCount
- Package as
.tgz and install through the Market's custom-package upload.
- Move the old
appdata directory to the new app name (see above).
Each of these five validation errors was clear and actionable — that part of the new validator works well. The problem is that Studio produces packages that cannot pass it, and offers no migration path.
Suggested fixes
- Ship a Studio release compatible with 1.12.6 that queries the
upload source instead of the removed studio source, and publish it before or together with the platform upgrade.
- Have
upgrade-1126-remove-studio-source either keep a compatibility alias for studio, or block/warn on upgrading while an incompatible studio-server is installed.
- Do not let Apply uninstall the running app before the reinstall has been validated. Currently a failed validation leaves a previously working app permanently down — that is the difference between an error message and an outage.
- Fix the format string at
chart_op.go:108; the underlying error is currently discarded (err=%!v(MISSING)), which makes this class of failure much harder to diagnose than it needs to be.
- Allow the
-dev suffix that Studio itself generates, or migrate existing dev app names automatically.
- Warn when a rename would detach an existing
appdata directory.
Impact
On a single-user system this took a production application offline for several hours and required hand-editing chart internals to recover. Anyone running a self-built app from Studio will hit this the first time they click Apply after upgrading to 1.12.6, and the app will stay down until they do the same manual migration.
(The username in the log excerpts has been replaced with <user>.)
Olares 1.12.6: Studio dev apps can no longer be installed —
Source data not found, and no Studio version is compatible with 1.12.6Summary
After upgrading to Olares 1.12.6, no application developed in Studio can be installed or re-applied any more. Clicking Apply on an existing dev app uninstalls it and then fails to reinstall, leaving the app permanently down.
The root cause appears to be that the 1.12.6 chart-repository migration
upgrade-1126-remove-studio-sourceremoves the chart source namedstudio, while the installedstudio-serverstill queries the repository withSource: studio. In addition, the Studio app itself declaresCompatibility: Olares >=1.12.3-0,<1.12.6, so there is currently no Studio release that is compatible with 1.12.6 and the Market offers no update.Recovering the app was possible only by hand-migrating the chart to manifest
v3and uploading it as a custom package — which in turn detached the app's persistentappdatadirectory (see Secondary issue).Environment
The affected app is a plain Deployment + Service created in Studio from a Docker image. It had been installed and re-applied many times without problems before the 1.12.6 upgrade.
Steps to reproduce
Evidence from the logs
studio-server— the chart upload itself succeeds; the follow-up version query fails:(Note the broken format string on the last line —
erris never passed, so the real error is lost.)chartrepo— the query arrives withSource: studio:chartrepo, at startup — thestudiosource has been removed by the 1.12.6 migration:chartrepo— meanwhile the same app resolves fine under theuploadsource:So
Source data not foundis literal: the source namedstudiono longer exists.studio-serverv0.1.73 has not been updated to queryupload.The compatibility dead end
Because Studio's own install path is broken, the remaining route is the Market's custom-package upload. That path is blocked by a contradiction:
Uploading a
v1manifest is rejected unless the system dependency is narrowed:Installing the resulting package is then rejected because the running system is 1.12.6:
No version range can satisfy both: the validator requires an upper bound of
<1.12.6, and the installer requires the range to include the running 1.12.6.v1applications are therefore uninstallable on 1.12.6 by construction.The same bound applies to Studio itself. The Market shows:
There is no update offered, and the newest published Studio declares itself incompatible with 1.12.6.
Additional finding: Studio-generated names cannot pass the new validator
Studio names every dev app
<name>-dev. Installing such an app through the Market's custom-package route fails on the new folder-name rule:A hyphen is not allowed, so no Studio-generated app name can ever satisfy this validator. This forces users to rename the app, which has the consequence described below.
Secondary issue: renaming an app detaches its appdata
Charts generated by Studio mount persistent data via:
.Values.userspace.appDatais derived from the application name. Renaming the app (which the folder-name rule above makes mandatory) silently changes the resolved path — in this case from…/claudebot-dev/claudebot/to…/claudebot/claudebot/.The app then starts successfully against an empty directory.
/healthreports the data directory as existing, the container comes up, and nothing signals that the previous data is not attached. In this case the application's file-sync process started against an empty source directory; only its own delete-protection prevented the remote copy from being emptied.Suggestion: when an app is installed with
permission.appData: trueand the resolved appdata directory is newly created while a directory for a previous name still exists, warn the user, or offer to carry the data over.Workaround
For the record, this sequence restored the app on 1.12.6, without Studio:
Chart.yaml,OlaresManifest.yaml,values.yaml,templates/).^[a-z0-9]{1,30}$.OlaresManifest.yamlto manifest0.12.0/apiVersion: v3: addapiVersion, addworkloadReplicas, removemetadata.appidandmetadata.target, setpermission.appCommon/externalDataexplicitly, use the_v112category names, and set the dependency toolares >=1.12.6-0.templates/deployment.yaml, setstrategy: {type: Recreate}— required because the chart mounts ahostPath:deployment <name> can not enable rolling update with hostpathworkloads.<name>.replicaCountinvalues.yamland reference it fromspec.replicas:templates/deployment.yaml: spec.replicas is set to "1"; it must reference .Values.workloads.<name>.replicaCount.tgzand install through the Market's custom-package upload.appdatadirectory to the new app name (see above).Each of these five validation errors was clear and actionable — that part of the new validator works well. The problem is that Studio produces packages that cannot pass it, and offers no migration path.
Suggested fixes
uploadsource instead of the removedstudiosource, and publish it before or together with the platform upgrade.upgrade-1126-remove-studio-sourceeither keep a compatibility alias forstudio, or block/warn on upgrading while an incompatiblestudio-serveris installed.chart_op.go:108; the underlying error is currently discarded (err=%!v(MISSING)), which makes this class of failure much harder to diagnose than it needs to be.-devsuffix that Studio itself generates, or migrate existing dev app names automatically.appdatadirectory.Impact
On a single-user system this took a production application offline for several hours and required hand-editing chart internals to recover. Anyone running a self-built app from Studio will hit this the first time they click Apply after upgrading to 1.12.6, and the app will stay down until they do the same manual migration.
(The username in the log excerpts has been replaced with
# Olares 1.12.6: Studio dev apps can no longer be installed — `Source data not found`, and no Studio version is compatible with 1.12.6<user>.)Summary
After upgrading to Olares 1.12.6, no application developed in Studio can be installed or re-applied any more. Clicking Apply on an existing dev app uninstalls it and then fails to reinstall, leaving the app permanently down.
The root cause appears to be that the 1.12.6 chart-repository migration
upgrade-1126-remove-studio-sourceremoves the chart source namedstudio, while the installedstudio-serverstill queries the repository withSource: studio. In addition, the Studio app itself declaresCompatibility: Olares >=1.12.3-0,<1.12.6, so there is currently no Studio release that is compatible with 1.12.6 and the Market offers no update.Recovering the app was possible only by hand-migrating the chart to manifest
v3and uploading it as a custom package — which in turn detached the app's persistentappdatadirectory (see [Secondary issue](#secondary-issue-renaming-an-app-detaches-its-appdata)).Environment
studio-serverbeclab/studio-server:v0.1.73dynamic-chart-repositorybeclab/dynamic-chart-repository:v0.3.49app-servicebeclab/app-service:0.5.67The affected app is a plain Deployment + Service created in Studio from a Docker image. It had been installed and re-applied many times without problems before the 1.12.6 upgrade.
Steps to reproduce
Evidence from the logs
studio-server— the chart upload itself succeeds; the follow-up version query fails:(Note the broken format string on the last line —
erris never passed, so the real error is lost.)chartrepo— the query arrives withSource: studio:chartrepo, at startup — thestudiosource has been removed by the 1.12.6 migration:chartrepo— meanwhile the same app resolves fine under theuploadsource:So
Source data not foundis literal: the source namedstudiono longer exists.studio-serverv0.1.73 has not been updated to queryupload.The compatibility dead end
Because Studio's own install path is broken, the remaining route is the Market's custom-package upload. That path is blocked by a contradiction:
Uploading a
v1manifest is rejected unless the system dependency is narrowed:Installing the resulting package is then rejected because the running system is 1.12.6:
No version range can satisfy both: the validator requires an upper bound of
<1.12.6, and the installer requires the range to include the running 1.12.6.v1applications are therefore uninstallable on 1.12.6 by construction.The same bound applies to Studio itself. The Market shows:
There is no update offered, and the newest published Studio declares itself incompatible with 1.12.6.
Additional finding: Studio-generated names cannot pass the new validator
Studio names every dev app
<name>-dev. Installing such an app through the Market's custom-package route fails on the new folder-name rule:A hyphen is not allowed, so no Studio-generated app name can ever satisfy this validator. This forces users to rename the app, which has the consequence described below.
Secondary issue: renaming an app detaches its appdata
Charts generated by Studio mount persistent data via:
.Values.userspace.appDatais derived from the application name. Renaming the app (which the folder-name rule above makes mandatory) silently changes the resolved path — in this case from…/claudebot-dev/claudebot/to…/claudebot/claudebot/.The app then starts successfully against an empty directory.
/healthreports the data directory as existing, the container comes up, and nothing signals that the previous data is not attached. In this case the application's file-sync process started against an empty source directory; only its own delete-protection prevented the remote copy from being emptied.Suggestion: when an app is installed with
permission.appData: trueand the resolved appdata directory is newly created while a directory for a previous name still exists, warn the user, or offer to carry the data over.Workaround
For the record, this sequence restored the app on 1.12.6, without Studio:
Chart.yaml,OlaresManifest.yaml,values.yaml,templates/).^[a-z0-9]{1,30}$.OlaresManifest.yamlto manifest0.12.0/apiVersion: v3: addapiVersion, addworkloadReplicas, removemetadata.appidandmetadata.target, setpermission.appCommon/externalDataexplicitly, use the_v112category names, and set the dependency toolares >=1.12.6-0.templates/deployment.yaml, setstrategy: {type: Recreate}— required because the chart mounts ahostPath:deployment <name> can not enable rolling update with hostpathworkloads.<name>.replicaCountinvalues.yamland reference it fromspec.replicas:templates/deployment.yaml: spec.replicas is set to "1"; it must reference .Values.workloads.<name>.replicaCount.tgzand install through the Market's custom-package upload.appdatadirectory to the new app name (see above).Each of these five validation errors was clear and actionable — that part of the new validator works well. The problem is that Studio produces packages that cannot pass it, and offers no migration path.
Suggested fixes
uploadsource instead of the removedstudiosource, and publish it before or together with the platform upgrade.upgrade-1126-remove-studio-sourceeither keep a compatibility alias forstudio, or block/warn on upgrading while an incompatiblestudio-serveris installed.chart_op.go:108; the underlying error is currently discarded (err=%!v(MISSING)), which makes this class of failure much harder to diagnose than it needs to be.-devsuffix that Studio itself generates, or migrate existing dev app names automatically.appdatadirectory.Impact
On a single-user system this took a production application offline for several hours and required hand-editing chart internals to recover. Anyone running a self-built app from Studio will hit this the first time they click Apply after upgrading to 1.12.6, and the app will stay down until they do the same manual migration.
(The username in the log excerpts has been replaced with
<user>.)