Managed-repo data-app deploy fails "could not read Username" on stacks without platform credential injection

[padak]

Summary

A pure Keboola-managed-repo data app (data-app create --use-managed-git-repo, no parameters.dataApp.git block) does not deploy on the us-east4.gcp.keboola.com stack: the data-app runtime's git clone of the managed repo fails because no credentials are available to it. The deploy silently reverts desiredState: running → stopped and the container never starts.

This appears to be a platform / sandboxes-service behavior (credential injection for managed repos) rather than a kbagent bug, but I'm filing it here to track the kbagent-side workaround and the dependency. Feel free to move it to the platform tracker.

Environment

• kbagent: 0.65.0 (feature branch feat/data-app-managed-git-repo)
• Stack: https://connection.us-east4.gcp.keboola.com (Data Science API data-science.us-east4.gcp.keboola.com)
• App type: python-js

Steps to reproduce

# 1. Create a managed-repo app (empty Keboola-hosted repo, no git block, no-deploy)
kbagent data-app create --project P --name "X" --slug x \
  --use-managed-git-repo --type python-js --auth public

# 2. Mint a credential + push code to the managed repo URL (data-app git-repo shows it)
kbagent data-app git-credentials-create --project P --app-id <ID> \
  --type http_token --permissions readWrite --yes
git push "https://<token>@git.us-east4.gcp.keboola.com/keboola/app-<ID>.git" HEAD:main

# 3. Deploy (no credential wired into the config -- relying on the platform)
kbagent data-app deploy --project P --app-id <ID> --wait

Actual result

The deploy times out; the app stays stopped. data-app runs shows the real reason (a setup-phase failure with no container logs):

reason: StartupProbeFailed
message:
  [TIMING] Starting: app_setup
  Cloning into '/app'...
  fatal: could not read Username for 'https://git.us-east4.gcp.keboola.com': No such device or address

A control external-repo app in the same project deploys and serves fine, so the failure is specific to managed-repo source resolution at deploy time — the runtime has no credential to clone the managed repo.

Expected result

Per the keboola/mcp-server RFC feature_spec/managed_repo_data_apps_mvp/RFC.md, a prod managed app is created with useManagedGitRepo=true and no parameters.dataApp.git block, and is then deployed directly — i.e. the prod app carries no credential of its own. That only works if the platform injects managed-repo credentials at deploy time. On us-east4.gcp that injection does not happen, so a pure managed app cannot deploy.

Open questions

1. Is managed-repo credential injection at deploy expected to work on all stacks, or is it gated by a feature flag / stack version? (The RFC was validated on canary-orion.)
2. If it should work everywhere, this is a sandboxes-service gap — the runtime needs to authenticate the managed-repo clone without the caller wiring a credential.
3. If wiring a credential is the intended pattern for these stacks, that should be documented (and kbagent's workaround below is the right shape).

kbagent workaround (shipped in 0.65.0)

data-app git-bind-credential mints an http_token ON the app, encrypts it under the project KMS, and writes parameters.dataApp.git = {repository, username (placeholder), "#password" (KBC:: ciphertext), branch} — the same external-git block the RFC's dev twin uses. After binding, data-app deploy clones + builds + runs. Verified live: a tic-tac-toe app then deploys and serves from its managed repo.

Two related kbagent fixes landed alongside:

• data-app deploy now pins the latest Storage configVersion when a git block is present and omits it only for a pure managed repo (deploys from managedGitRepoId). Previously it always pinned, which pointed managed deploys at a config snapshot with no git source.
• data-app runs exposes /apps/{id}/runs (failure_reason + startup_logs), the only place setup-phase failures like the clone error surface.

Honest caveat

I verified the failure on us-east4.gcp directly. The claim that the platform injects credentials on canary-orion is inferred from the RFC (its prod app has no credential block yet deploys), not something I tested first-hand. Someone with canary access should confirm whether this is a stack-version difference or a missing feature on us-east4.gcp.

[padak]

Closing as not a platform bug — the original premise was wrong. Apologies for the noise.

A clean repro today (kbagent 0.65.0, us-east4.gcp) shows the canonical managed-repo flow works and the platform does inject clone credentials at deploy time — exactly as tests/e2e/scripts/testManagedGitRepo.sh does it:

• create useManagedGitRepo:true app → git push code → PATCH /apps/{id} {desiredState:"running"} (no configVersion, no git block in the Storage config) → app reaches running and serves (HTTP 200).

The original could not read Username symptom was a kbagent bug, not a platform gap. kbagent's deploy always pinned configVersion; pinning a managed app's Storage config (which has no parameters.dataApp.git block) makes the deploy use that snapshot instead of the managedGitRepoId injection path, so the runtime has no repository/credentials. Decisive repro on two fresh managed apps:

• deploy with configVersion omitted → ✅ running + serving
• deploy with configVersion pinned → ❌ StartupProbeFailed: dataApp.git.repository is required

Fixed in kbagent 0.65.0 by omitting configVersion for pure managed-repo deploys (matching the platform contract). No platform change is needed, so closing this.