zyratlo opened a new issue, #7636: URL: https://github.com/apache/texera/issues/7636
### Feature Summary The Python notebook migration tool stores a notebook and its cell-to-operator mapping so the Jupyter panel can reattach them when a generated workflow is reopened. Both the store and the fetch paths currently key this data by a hardcoded workflow version id of 1. - Store: `NotebookMigrationService.storeNotebookAndMapping(...)` defaults its `vid` parameter to 1, and the dashboard generate flow omits it. (`frontend/src/app/workspace/service/notebook-migration/notebook-migration.service.ts`) - Fetch: `JupyterPanelService.fetchNotebookAndMapping(...)` hardcodes `vId = 1` and already carries a `// Future work: add dynamic fetching of current workflow vId` comment. (`frontend/src/app/workspace/service/jupyter-panel/jupyter-panel.service.ts`) The feature works today because store and fetch use the same constant, so the keys line up and the panel reattaches. The value itself is wrong. `workflow_version.vid` is a global `SERIAL PRIMARY KEY`, not a per-workflow version counter (`sql/texera_ddl.sql`, workflow_version table). The mapping table keys on `(wid, vid, nid)` and declares `FOREIGN KEY (vid) REFERENCES workflow_version(vid) ON DELETE CASCADE`. Consequences of pinning every generated workflow's mapping to vid=1: 1. Every generated workflow's mapping is FK-anchored to a single unrelated version row (whichever workflow owns global vid=1). 2. Deleting the workflow that owns vid=1 cascade-deletes every generated notebook mapping. 3. If no row with vid=1 exists, the store insert violates the foreign key and fails. ### Proposed Solution or Design Resolve and persist the actual version id for the workflow instead of the constant: 1. Surface the real `vid` assigned to the newly created workflow (extend the `createWorkflow` response if it does not already return it). 2. Pass that real `vid` into `storeNotebookAndMapping` from the dashboard generate flow. 3. Resolve the current workflow's version dynamically on the fetch side, so the fetch key matches the stored one. This is the work the existing fetch-side TODO defers. Store and fetch must stay in agreement: changing only one side breaks the match and the panel stops reattaching. The solution should have: - Generated workflows store their mapping under their own workflow version id. - The Jupyter panel reattaches the mapping using the same resolved version id. - Deleting an unrelated workflow does not remove another workflow's mapping. - The hardcoded vid=1 and its Future work comment are removed from both paths. ### Affected Area Other -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
