Pipeline fails to start: "internalServerError executing request"

[JP_Wisco]

Edits: Accidentally edited the wrong post, then undid the edit, then edited to add edits note.

I don't have a lot of experience with pipelines but didn't find this issue on a skim of the troubleshooting documentation or in a google search. I don't know how to begin to resolve this, it seems like the failure occurs before my pipeline activities even start.

Issue: The scheduled refreshes are all failing. Running the pipeline manually provides a little notification that the pipeline successfully started and immediately provides a notification that the pipeline failed. Looking into the error simple provides "internalServerError executing request". The first couple of steps of the pipeline are lookup activities, but it doesn’t even look like those are initiating before the run fails.

Occurrence: The pipeline was working well on a 15-minute schedule and didn't stop working after I made a copy of the pipeline to test with a refactored notebook. Running the pipeline copy is the first time I saw the error. I couldn’t resolve it and ended up altering the original working pipeline. The updated pipeline continued to work without issue for approximately a week.

[Stinkys]

I have just encountered this error on a copied pipeline. I had to delete the pipeline and create it again from scratch. Descriptive error was much descriptive.

[AdeV-Oly]

After copying a pipeline, I encountered this fail as well.

The issue got resolved by signing in to my Office 365 Outlook account in one of the Outlook 365 activities of our pipeline and allowing access. 🙂

[igork]

Thank you, that helped me 🙂 

[m98ateusz]

I am facing the same issue right now. Pipeline is failing after 1 sec, before even run notebook. Its failing via schedule and via manuall process

[v-cboorla-msft]

Hi @JP_Wisco 

Thanks for using Microsoft Fabric Community.

Apologies for the inconvenience that you are facing here.

Could you please share below details to troubleshoot the issue:

• Can you confirm if this error is specific to this pipeline, or have similar errors been observed in other pipelines as well?
• To better understand the error, could you outline the activities and transformations used within the failing pipeline?
• Can you provide details on the source and target configurations for the pipeline?
• Could you see data preview if having a Data Flow activity in the pipeline?

Thanks.

[JP_Wisco]

Thank you for the response. I hopped into the pipeline to provide a detailed response and initiated a manual run while I was at it. The run kicked off without issue and fully succeeded 20 minutes later. After three straight days of scheduled fails, I have a manual success and was able to restart the schedule without issue. I haven't made any changes to the pipeline, sourcess or destinations beyond unpublishing the in-development Power BI reporting that was built on this data. I guess I'm cured until it happens again?

• Beyond the copy of my original pipeline, and now my original pipeline, I've had this error in one other unrelated pipeline.
• This pipeline starts with two Lookup activities and a set variable activity grabbing info from lakehouse tables, a notebook to delete older .json files in a datalake directory, and then a ForEach with a copy activity to make a series of API calls and save the .json files to my directory. The pipeline finishes up with a notebook to rebuild my reporting delta tables and a couple of final activities to send me an email and make a Teams post if the refresh fails.
• Sources for the lookups are delta tables in my datalake, source for the copy is a software vendor API, and the source for my notebooks are the datalake file directory. I had the pipeline scheduled to run every 15 minutes, dialed it back to every 60 minutes to monitor after a notebook refactor, and was observing it consume less than 3% of our trial capacity compute. I have some additional refactoring scoped to target 5-minute refreshes at 2.5% capacity, but that's tables while I work on the Power BI reportin.
• The last two activities, Office 365 Outlook and Teams are noted as being in (Preview). I previously removed dataflow activities from all of my pipelines over four weeks ago. They were functioning, but felt clunky with schema change error when loading to delta tables. It would also take five to fifteen minutes for a dataflow to build a single table from my data, where a notebook now rebuilds the entire reporting database in less than two minutes.

[dmc1977]

I made a copy of the pipeline to test

When making a copy of a pipeline and you have a PipelineName system variable in your activities , Teams activity in my case, this error occurs. Removing the PipelineName variable and re-adding it resolves the issue. I'm assuming the pipeline renaming causes the issue but didn't fully test scenarios.  

[igork]

@dmc1977 
Thanks for the response.
What if three workspaces (sandbox - preprod - prod) form a part of the deployment pipeline?
How to overcome this issue in this case since we need to deploy sanbox to preprod and then preprod to prod?

[v-cboorla-msft · Accepted solution]

Hi @JP_Wisco 

Apologies for the delay in response from my end.

Following up to see whether the issue got resolved or still you are facing the issue?

The error "Internal Server Error - Executing requests." could be a transient network issue.

If the issue still persists. Please reach out to our support team so they can do a more thorough investigation on why this it is happening. It's difficult to tell what could be the reason for this performance. If its a bug, we will definitely would like to know and properly address it.

Please go ahead and raise a support ticket to reach our support team:

https://support.fabric.microsoft.com/support

After creating a Support ticket please provide the ticket number as it would help us to track for more information.

Thank you.

[v-cboorla-msft]

Hi @JP_Wisco 

We haven’t heard from you on the last response and was just checking back to see if you've had a chance to submit a support ticket. If you have, a reference to the ticket number would be greatly appreciated. This will allow us to track the progress of your request and ensure you receive the most efficient support possible.

Thanks

[JP_Wisco]

Thank you for the follow-up. I haven't created a ticket, and haven't run into any persistent or even frequent disruptions since this event.

I've never seen a transient network issue persist for a full weekend, but I haven't had any problems with it since I halted the schedule, gave it half a day to rest, and then restarted the schedule.