Engineering & roadmap

PB-018: Publish matches Fabric items by id, not display name

A new name. The same foundation. KratosForge is the upcoming name for Fabric Desktop by KratosBI. These guides preserve the app’s current labels and paths.

State: Proposed. Not approved for implementation. Priority: P2. Owner when approved: Master product (unassigned).

1. PR title and ID#

Publish updates the Fabric notebook it published before, even after a rename (PB-018)

2. Business problem#

Renaming a notebook on the PC or in Fabric makes the next publish create a second Fabric item, leaving an orphan that schedules and pipelines may still call.

3. Current verified behavior#

  • fabric_api.py save_notebook finds an existing notebook by displayName and creates a new one if none matches.
  • cloud_service.py _publish then calls _record_notebook_item, which stores the item id in the workload store (workload_service.py), but publish never reads it back.

4. Desired behavior#

Publish uses the recorded item id for this notebook and workspace when it exists and the item is still there; it updates that item's definition (and display name if the local name changed). It falls back to name matching only when no id is recorded, and creates a new item with a note if the recorded item was deleted.

5. In scope and out of scope#

In scope: publish, Run in Fabric (which publishes first), the schedule lookup that also matches by name (_notebook_item). Out of scope: other item types.

6. Architecture and files#

fabric_api.py (save_notebook takes an optional item id), cloud_service.py (_publish, _notebook_item), workload_service.py (read the recorded link), sidecar/tests/test_notebook_publish.py.

7. Functional requirements#

As section 4. A rename in Fabric is not overwritten unless the user renamed locally too.

8. Nonfunctional requirements#

No extra API calls when an id is recorded beyond one item GET.

9. Dependencies#

None.

10. Security and compatibility#

Updating by id must stay inside the workspace the notebook publishes to (check the item's workspace before writing). Existing notebooks with no recorded id keep today's behavior.

11. Acceptance criteria#

  • Test: publish, rename locally, publish again: one item, updated.
  • Test: recorded item deleted: new item created with a note.
  • Existing publish tests pass.

12. Unit and integration tests#

Two tests above with the fake Fabric client.

13. Manual verification#

On a tenant: publish, rename, publish, confirm one item in the workspace.

14. Documentation#

docs/notebooks.md publish section.

15. Rollback#

Revert; recorded ids are already stored today, so nothing to migrate.

16. Definition of Done#

Merged, tests green, FEAT-FAB-06 limitation removed after review.

Need a hand?

Find a fix in troubleshooting, or share a reproducible issue with the community.

Get support ↗Improve this guide on GitHub ↗

Search documentation

Start typing to search all 105 guides.

Search runs in your browser esc to close