Internal Server Error when starting compute session in Prompt Flow in classic Foundry UI

Yuzhen Liu 25 Reputation points
2026-05-13T22:28:01.2833333+00:00

I’m encountering an issue in Azure AI Foundry/Prompt Flow where the starting compute session operation fails with an internal server error, with no additional information.

Error message:

Session operation failed: InternalServerError
Trace ID: fc73b2e1-5789-4084-83c8-67f07e5e1e30

This issue occurs when attempting to operate the Prompt Flow compute session.

Anyway to debug this?

Azure Machine Learning

Answer accepted by question author
Sina Salam 31,536 Reputation points Volunteer Moderator
2026-05-31T16:19:40.4066667+00:00

Hello Yuzhen Liu,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having Prompt Flow compute session startup failure in Microsoft Foundry (classic) with Session operation failed: InternalServerError.

The failure is generic and it's typically caused by one or more of the following mandatory dependencies not being satisfied for Prompt Flow compute sessions as listed in the official links below:

The best practice resolution for all the above is to:

  • Assign AzureML Data Scientist to the affected user on the workspace
  • Verify that workspaceblobstore is the default datastore and uses Blob storage
  • Verify that workspaceworkingdirectory exists and is a File Share datastore
  • If the flow uses customization, keep packages in requirements.txt, remove pinned promptflow packages, and use only a custom image built from the official Prompt Flow runtime base image
  • If using ACR or a user-assigned managed identity, grant the identity ACR pull access
  • If networking is private, validate storage, ACR, private endpoint, and managed identity requirements
  • If the error still persists, open an Azure Support request with the Trace ID, UTC timestamp, PortalDiagnostics.json, and HAR/browser trace so Microsoft can inspect the backend logs directly

Therefore, check one after the other: After correcting the workspace prerequisites, runtime definition, identity permissions, and network dependencies, Prompt Flow compute sessions start normally. If the issue still reproduces after those validations, the remaining cause is service-side and must be confirmed by Microsoft through backend diagnostics collected from the submitted support case.

Use the below resource links for more reading and implementation steps:

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.


Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

4 additional answers

Sort by: Oldest
  1. AI answer

    2026-05-13T22:28:16.86+00:00

    For an internal server error when starting a Prompt Flow compute session in the classic Foundry UI, the available guidance focuses on checking the compute session environment and image build, because missing dependencies or image build failures commonly surface as opaque runtime errors.

    Use the following checks and debugging steps:

    1. Verify required Python packages and base image
      • If using a default environment, ensure the compute session image is on the latest version. An outdated image can miss required packages and cause failures when the session starts.
      • If using a custom base image, confirm that all required packages are installed in the Docker context. A missing module often appears as No module named XXX once logs are available, but can also manifest as generic failures at session start.
      • For Prompt Flow in Azure Machine Learning, compute sessions support requirements.txt or a custom base image specified in flow.dag.yaml. The recommended approach is:
        • Prefer requirements.txt for typical Python dependencies; the platform runs pip install -r requirements.txt.
        • Only build a custom image if non-Python dependencies are needed, following the “Customize base image” guidance.
        • Do not pin promptflow or promptflow-tools versions in requirements.txt, because they are already included in the base image and pinning older versions can cause unexpected behavior.
    2. Ensure a supported Prompt Flow base image is used
      • Compute sessions cannot use arbitrary base images. The base image must be one of the Prompt Flow–provided images; otherwise, the session can fail to start with low-information errors.
      • If a custom image is required, build it on top of a Prompt Flow base image and reference it in flow.dag.yaml as documented in the compute-session customization guidance.
    3. Check for environment image build failures
      • Internal server errors during session start or deployment can be caused by image build failures in the underlying Azure ML environment.
      • For deployments, an ImageBuildFailure or timeout while waiting for the environment image is a common symptom. In those cases, the build log in the workspace storage account contains the real error.
      • For a compute session that fails to start, inspect the corresponding environment/image build logs in the Azure ML workspace or storage account (under the environment’s container path) to see if dependency installation or Docker build failed.
    4. Confirm serverless instance and compute session configuration
      • In the Foundry/Prompt Flow experience, the serverless instance used by a compute session can be viewed on the compute session list tab under the Compute page. Confirm that:
        • The session is bound to a valid serverless instance.
        • The instance is healthy and not in a failed or deallocated state.
    5. If using a custom base image in Foundry classic
      • When flows are deployed or run with a custom base image, misconfiguration can cause backend errors:
        • Ensure the container image URI from the custom environment detail page is correctly set as the flow base image in flow.dag.yaml.
        • When deploying from the UI, select Use environment of current flow definition so the backend builds the environment from that base image plus requirements.txt.
        • Alternatively, ensure inference_config is correctly added in the custom environment definition if that pattern is used.
    6. Re-run after updating runtime or environment
      • If the flow or compute session is tied to an older runtime, upgrade the compute instance/runtime as per the “Upgrade compute instance runtime” guidance, re-run the flow in the latest runtime, and then start the compute session again.
    7. Use the trace ID with Azure support
      • The Trace ID in the error (fc73b2e1-5789-4084-83c8-67f07e5e1e30) is primarily for backend diagnostics. After verifying the above configuration and environment points, open a support ticket and provide this trace ID so the service team can correlate it with internal logs.

    These steps focus on surfacing the underlying cause (image build failure, missing packages, unsupported base image, or outdated runtime) that is currently hidden behind the generic InternalServerError.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. kagiyama yutaka 5,740 Reputation points
    2026-05-14T03:58:40.22+00:00

    I think the simplest way to debug this is to reset the compute state and let Foundry re-check the environment. Stopping and starting the compute, then opening a fresh compute session, usually makes the real error appear, and checking the workspace logs is the next reliable place to see details.

    Was this answer helpful?

    0 comments No comments

  3. Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator
    2026-05-31T09:05:44.5633333+00:00

    Hello @Yuzhen Liu ,

    Welcome to Microsoft Q&A .Thank you for reaching out to us.

    The failure pattern indicates a likely service or provisioning-related condition, especially given its reproducibility across new environments. The backend engineering teams continue active monitoring and investigation, and recovery actions are applied as needed to stabilize the experience.

    Appreciation is extended for the patience while this is being addressed.

    When a compute session fails with Session operation failed: InternalServerError and the behavior is reproducible across fresh environments, the issue is less likely to be limited to a specific flow configuration. Instead, it may be influenced by:

    1. service-side provisioning or orchestration conditions
    2. regional capacity or dependency constraints
    3. compute session initialization before runtime setup
    4. in some cases, environment/image-related issues

    To ensure complete coverage, the following steps might be helpful-

    1. Checking service health -Review service health for the region to identify any ongoing impact to compute session provisioning or related services.
    2. Validating quota and regional capacity
      1. Confirm sufficient compute quota is available.
      2. Verify no subscription or regional limits are preventing allocation.
    3. Performing region isolation test - Attempt the same operation in an alternate region if feasible.
      1. If it succeeds , itindicates region-specific issue
      2. else if failure it suggests broader configuration or service condition
    4. Reviewing compute session logs Navigate to the compute session logs and review details such as
      1. environment/image build failures
      2. dependency errors (e.g., missing modules)
      3. provisioning or timeout-related messages
      If logs appear empty, it may indicate that failure occurs early in backend provisioning.
    5. Verifying workspace dependencies
      1. Confirm networking, private endpoints, or DNS are not restricting required services
      2. Validate workspace and storage access configuration where applicable
    6. Retrying after cleanup
    7. Reattempt session creation after clearing any partially created sessions
      1. This helps rule out transient backend conditions

    The following references might be helpful , please check them out

    Please let us know if the response was helpful

     

    Thank you

     

    Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the response was helpful. This will be benefitting other community members who face the same issue.

    Was this answer helpful?

    0 comments No comments

  4. Andrew Taylor - COREZENN 1,395 Reputation points Volunteer Moderator
    2026-05-31T19:28:31.0633333+00:00

    Hello @Yuzhen Liu

    Thank you for reaching out on Microsoft Q&A!

    An InternalServerError during a compute session creation—especially without additional error details—typically indicates an unexpected backend service failure rather than a configuration error on your end.

    The Trace ID provided in your error message is generated specifically for correlating this failure with our internal system logs.

    To resolve or debug this issue, please follow these steps:

    1. Retry the Operation: Transient service disruptions or capacity allocations can sometimes trigger this error. Please wait a few minutes and try starting the compute session again.
    2. Review Network/Image Configurations: If you are using a custom base image or deploying within a secured Virtual Network (VNet), underlying timeouts or image pull failures can occasionally be masked as an internal server error. Ensure your image dependencies are correct and your VNet allows the required Azure ML and Foundry endpoints.
    3. Contact Support: If the error persists after retrying, we will need to investigate the backend telemetry. Please open an Azure Support ticket and provide the exact Trace ID (fc73b2e1-5789-4084-83c8-67f07e5e1e30) and the timestamp of the failure. Our engineering team can use this Trace ID to pinpoint the exact cause of the failure.

    Please let us know if you need assistance opening a support ticket!

    Best regards, Andrew S Taylor Microsoft Q&A Moderator

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.