data-app deploy on a managed-repo app keeps an old config version, so runtime.workspace and storage mappings never apply

[trobertsonkbc]

Summary

kbagent data-app create --use-managed-git-repo leaves the app's Storage configuration without parameters.dataApp.git. The platform writes the git block, then kbagent's own PUT overwrites the whole configuration without it. Deploying that latest version fails at startup with:

[ERROR] dataApp.git.repository is required in /data/config.json

Environment

• kbagent v0.95.0, Windows 11
• Stack connection.us-east4.gcp.keboola.com, project 133, app type python-js

Reproduction

kbagent data-app create --project P --name "X" --slug x --use-managed-git-repo --auth password --no-deploy

Config versions after create (all written by the kbagent token):

Version	Change description	parameters.dataApp.git
1	Configuration created	absent
2	Set App ID	absent
3	Configure managed Git repository	present (repository, branch: main, private: true)
4	Initial data-app config via kbagent data-app create	absent, dropped

Version 4 adds runtime.workspace.enabled and runtime.backend.size but rebuilds parameters from scratch, so the git block written in v3 is lost.

After pushing code to the managed repo:

• kbagent data-app deploy --app-id N --wait (no --config-version) reported config_version: "3", deploying v3, which has the git block but no runtime.workspace. The app started without WORKSPACE_ID / QUERY_SERVICE_URL.
• kbagent data-app deploy --app-id N --config-version <latest> fails with the error above.

Workaround

kbagent config update --component-id keboola.data-apps --config-id <cfg> --merge \
  --set 'parameters.dataApp.git={"repository":"https://git.<stack>/keboola/app-<id>.git","branch":"main","private":true}'
kbagent data-app deploy --app-id <id> --config-version <new latest> --wait

Expected

1. data-app create merges into the existing configuration (or re-reads it before the PUT), so parameters.dataApp.git survives.
2. data-app deploy without --config-version deploys the latest Storage configuration version, as its help text says ("Deploy the latest Storage config"). Here it deployed v3 while v5 existed.

Related

• data-app list returns no apps when the first /apps page holds only workspaces (no pagination) #798 (data-app list pagination)
• Separately: with a static non-master token, data-app git-credentials-create fails with "admin context is required". The create success message recommends that command as the next step, so it might mention that a session login (kbagent auth login) is needed.

[trobertsonkbc]

Correction: the missing git block is by design; the bug is that deploy ignores later config versions

After reading the kbagent source, I got the root cause wrong above.

What's intentional:

• DataAppService (create, step 3) deliberately writes no parameters.dataApp.git block for --use-managed-git-repo. The Git Service owns the link through app.managedGitRepoId.
• DataScienceClient.patch_app documents that a pure managed-repo app deploys from managedGitRepoId, so data-app deploy omits configVersion entirely ({desiredState, restartIfRunning}), matching keboola-mcp-server / Kai.

So v4 lacking the git block is expected, not a bug.

What actually went wrong:

1. kbagent data-app deploy --app-id N --wait (no --config-version) left the deployment record at configVersion: "3". v3 predates the runtime.workspace.enabled that create itself writes in v4, and the storage.output.tables (direct-grant) I added in v5.
2. The container therefore started without WORKSPACE_ID, BRANCH_ID or KBC_WORKSPACE_MANIFEST_PATH, even though the latest Storage config has Storage access enabled. data-app detail showed config_version_storage: "5" vs config_version_deployed: "3".
3. Pinning the latest version (--config-version 5) to pick up those settings then fails with dataApp.git.repository is required in /data/config.json, presumably because a pinned version is read from Storage and has no git block.

The only way to get both the managed-repo source and the current runtime config was to add the git block by hand (workaround above) and pin the latest version.

Suggested fix (either):

• For pure managed-repo apps, advance the deployment's config version when deploying, without requiring a git block in Storage. That may need platform support if configVersion + managed source can't be combined today.
• Or have create pin the deployment to the version its own PUT writes (v4 here), so runtime.workspace from --workspace (the default) actually takes effect, and document that later Storage config changes need the git-block workaround.

At minimum, data-app deploy --help ("Deploy the latest Storage config") should say that managed-repo apps don't do this.

Sorry for the misdirection in the original report.