403 forbidden rayfin up

What happened?

Issue: rayfin up db apply fails with 403 Forbidden — Only AppBackend artifact owner can perform this operation on AppBackend item App_1, even though the Fabric portal's item Settings → About confirms I am the owner. Refreshed the CLI login session and retried — same error.

This looks like the DAB/BaaS workload enforcing this check isn't reading current item ownership — a Fabric Apps (preview) platform issue, not a permissions gap on my end.

Steps to reproduce

Had a pre-existing AppBackend item (App_1) in the workspace, created earlier through the Fabric portal UI rather than this CLI session.

Ran npx rayfin init --item-id <App_1 item ID> --workspace-id to attach the local project to that existing item (chose "Start from scratch (configure manually)," confirmed overwrite of rayfin.yml only).

Ran npx rayfin up. Auth config, runtime settings, and static content all deployed successfully. The database-apply step failed: 403 Forbidden — Only AppBackend artifact owner can perform this operation

Ran npx rayfin login --select, re-authenticated as the same account, ran npx rayfin up db apply directly — same 403

Confirmed in the Fabric portal (App_1 → Settings → About) that this account is listed as the item's owner.

Ran npx rayfin login again for a fully fresh session, then npx rayfin up db apply again — same 403 persists

Environment

OS: Windows (PowerShell)
Project on OneDrive-synced local folder
@microsoft/rayfin-cli, -core, -data, -client, -auth-provider-fabric: ^1.33.2 (per package.json — worth confirming the exact resolved version with npm ls @microsoft/rayfin-cli since ^ allows a range)
Database dialect: mssql
Fabric tenant
Fabric workspace:
Target item: AppBackend
Services enabled in rayfin.yml: auth (fabric + password), data, staticHosting

Logs or screenshots

Start with package.json and run npm ls @microsoft/rayfin-cli to confirm the resolved versions, then review rayfin.yml and reproduce npx rayfin up db apply against the existing AppBackend item. Compare the successful deployment steps with the failing database-apply request and verify whether an owned item can complete that step without the 403 response.