Forum Discussion

Perez0s0's avatar
Perez0s0
Frequent Visitor
11 days ago
Solved

Deployed notebooks cannot start a session, but a copy of the same notebook works fine

Hi all,

I'm running into a strange issue with Microsoft Fabric Deployment Pipelines and was wondering if anyone else has experienced something similar.

Scenario

  • Source workspace: DEV
  • Target workspace: PROD
  • Deployment method: Fabric Deployment Pipeline

The deployment completes successfully and the notebook appears in the PROD workspace.

Problem

When I open the deployed notebook in PROD and try to start a session, I get:

 

"Your notebook session cannot be started. Please try running the notebook again. If the problem persists, check your network settings or contact support."

The notebook never reaches the first code cell. No code is executed at all.

What I've tested

  • Creating a brand new notebook in PROD works.
  • Creating a copy of the deployed notebook in the same PROD workspace works immediately.
  • The copied notebook can start a Spark session and execute code normally.
  • The original notebook deployed by the pipeline cannot start a session.
  • The notebook copy has the same owner as the deployed notebook.
data engineering
Data Pipeline
  • Perez0s0's avatar
    Perez0s0
    10 days ago

    We simulated the issue on a new workspace, deploying the same notebook to this workspace that's on the same capacity.
    There were no issues running the notebook this time. So at this point I was thinking it's at workspace level. 

    We switched the capacity of the workspace to the DEV capacity and were able to at least start a session but there was still some error I don't exactly remember. Then we switched the workspace back to the PROD capacity and things were running fine again.

    I have no idea what caused this bug(?), but everything seems to be running normal now. Also when we deploy new notebooks. To add to that, I do not believe the deployment pipeline had anything to do with this. I think existing items on the workspace must have lost some sort of connection. 

5 Replies

  • Perez0s0's avatar
    Perez0s0
    Frequent Visitor
    10 days ago

    We simulated the issue on a new workspace, deploying the same notebook to this workspace that's on the same capacity.
    There were no issues running the notebook this time. So at this point I was thinking it's at workspace level. 

    We switched the capacity of the workspace to the DEV capacity and were able to at least start a session but there was still some error I don't exactly remember. Then we switched the workspace back to the PROD capacity and things were running fine again.

    I have no idea what caused this bug(?), but everything seems to be running normal now. Also when we deploy new notebooks. To add to that, I do not believe the deployment pipeline had anything to do with this. I think existing items on the workspace must have lost some sort of connection. 

  • Perez0s0's avatar
    Perez0s0
    Frequent Visitor
    11 days ago

    This is additional error info:
    Diagnostic ID: xxx
    Timestamp: 2026-08-11T08:49:34.325Z
    Message: launch_kernel_error; j2areg [400] [object Object] JSON "launch_kernel_error; j2areg [400] [object Object]" Additional info: -

  • Yash8160's avatar
    Yash8160
    Advocate I
    11 days ago


    Compare Environment on broken vs copied notebook.
    Compare default Lakehouse.
    Detach/re-attach the Environment on the broken notebook.
    Remove/re-add the default Lakehouse.
    Save the notebook and retry.

     

  • tayloramy's avatar
    tayloramy
    Super User
    11 days ago

    Hi Perez0s0, 

     

    How are you tunning the deployment pipeline? Are you running it from your account, or from another account, or from an SPN? 

     

    Whatever account is running the deployment pipeline becomes the owner of the items, and notebooks generally run under the context of their owner, so this could be where your issue is coming from if you're not using your account (or the account of whoever created the notebook) to deploy it. 

     

    I've run into cases where I used an SPN to deploy a notebook, and the SPN did not have permissions to use Fabric REST APIs, so it could not actually run anything. 

     

    If that is not the issue, I recommend adding the notebooks (both working and non working) from PRD into git, and comparing the platform metadata for both. 

  • ShivekMaharaj's avatar
    ShivekMaharaj
    Impactful Individual
    11 days ago

    Hi Perez0s0,

     

    The fact that a copy of the deployed notebook works in the same PROD workspace is a useful clue. I would focus on the deployed notebook’s metadata/dependencies rather than the Spark code itself.

     

    Fabric notebooks can carry references to things such as the default Lakehouse and Environment. Microsoft documents that notebook dependency binding needs to be handled correctly across workspaces, and Lakehouse auto-binding for notebooks is not enabled by default.

     

    I would compare the working copy and the deployed notebook for:

    1. Default Lakehouse
    2. Attached Environment
    3. Any workspace-specific Lakehouse reference left in the notebook metadata
    4. Whether Lakehouse Auto-Binding is enabled for the notebook before deployment

    I would also try detaching the Lakehouse and Environment from the broken notebook, save it, then attach the PROD versions again and retry the session.

     

    Microsoft also notes in the notebook source control/deployment guidance that the default Lakehouse ID can remain in notebook metadata and may need to be manually rebound in the target workspace.

     

    Given the launch_kernel_error happens before the first cell runs, I would test those bindings before changing any notebook code.

     

    If rebinding the PROD Lakehouse/Environment makes the original deployed notebook start successfully, that would narrow this down quite nicely to deployment metadata rather than Spark capacity or code.