Skip to content

v0.87.0 — Data apps get Storage access by default

Choose a tag to compare

@MiroCillik MiroCillik released this 21 Aug 15:45
· 165 commits to main since this release
cc2f7da

Storage access for data apps is now on by default

kbagent data-app create gains --workspace / --no-workspace, defaulting ON. It writes runtime.workspace.enabled: true — the single switch that makes the platform provision the app's ephemeral workspace and inject WORKSPACE_ID, QUERY_SERVICE_URL and KBC_WORKSPACE_MANIFEST_PATH.

Why

kbagent never wrote that flag and offered no option to. An app that reads Storage — including every app built from the dataapp-developer skill's DuckDB-cached read-only pattern — deployed, reported state=running, and passed its health probe while unable to read a single row. The platform emits no diagnostic for this: an app that checks its own environment logs something like Missing env vars: WORKSPACE_ID, and one that doesn't crash-loops behind the probe instead. Silently serving zeros was the default outcome.

Upgrading

New apps need nothing. Apps created by kbagent 0.86.0 or earlier still have the dead data path — the authoritative check is the config, not the log:

kbagent --json config detail --project P --component-id keboola.data-apps \
  --config-id <cfg> | jq '.data.configuration.runtime'
# no "workspace": {"enabled": true}  ->  this is your bug

Retrofit (both steps — a config update alone never reaches the running container):

kbagent config update --project P --component-id keboola.data-apps \
  --config-id <cfg> --merge --set 'runtime.workspace.enabled=true'
kbagent data-app deploy --project P --app-id <ID> --wait

Notes

  • --no-workspace omits the key rather than writing enabled: false, so that request body is byte-identical to 0.86.0. Use it for an app that never touches Storage.
  • The block is a sibling of runtime.backend, matching what the UI and MCP's modify_python_js_data_app write.
  • Not gated on any project feature — the config option is the sole control.
  • Mirrored on the serve REST surface as "workspace": true in POST /data-apps/{project}, and reported as workspace in the --json envelope.
  • secrets-set now warns when a secret's derived env-var name collides with WORKSPACE_ID, QUERY_SERVICE_URL or KBC_WORKSPACE_MANIFEST_PATH — those are platform-injected once Storage access is on, so such a secret is silently shadowed.

Full changelog: kbagent changelog --limit 1 --full