Forum Discussion
User data function invocation failed (but works in testing)
Hi,
I'm having a strange issue where I get the following error, when trying to call a specific UDF from a power bi report:
And when I try running the same function as a part of a pipeline, I get the following error, referencing the same "invocation failed"
Call to provided Data function runAllCogsCalculations' failed with status InternalServerError' additional details - {"functionName":"runAllCogsCalculations","invocationId":"00000000-0000-0000-0000-000000000000","status":"Failed","errors":[{"errorCode":"WorkloadException","subErrorCode":"NotFound","message":"User data function: 'runAllCogsCalculations' invocation failed."}]}.
This issue emerged seemingly out of nowhere last night, when I was making changes to the function in question. However, the function still works exactly as it is supposed to in the fabric testing environment. I initially thought this was a fabric throttling issue, since I had hit the capacity earlier last night, but now that the issue persists I doubt that is the case.
I have checked that the function was exported correctly, updated the button slicer used to call it from the report, and refreshed the semantic model many times. Other UDFs called from the report still work as normal - although to be noted, the problematic function is the most computationally expensive one in the report / workspace.
After a long stint working with microsoft tech support (big thanks to Naeem), we finally found the source of the issue:
I had, not knowing better, used the line
udf = fn.UserDataFunctions()at the beginning of every (publicly visible) function in the document, like this:
udf = fn.UserDataFunctions() @udf.connection(argName="sqlDB", alias="COGSdb") @udf.function() async def runAllCogsCalculations(sqlDB: fn.FabricSqlConnection) -> str:While for some reason this does not cause issues in testing, it leads to all functions defined before the last instance of the line to be unavailable when published, without producing a clear error as to why.
Luckily, the solution is very simple: just remove all but the first use of "udf = fn.UserDataFunctions()" without changing anything else, and the issue should be resolved.
Hopefully this helps someone who's facing the same issue. I also made sure to report the problem somehow bypassing testing to microsoft, and I hope in the future there will be a proper error to prevent this.
3 Replies
After a long stint working with microsoft tech support (big thanks to Naeem), we finally found the source of the issue:
I had, not knowing better, used the line
udf = fn.UserDataFunctions()at the beginning of every (publicly visible) function in the document, like this:
udf = fn.UserDataFunctions() @udf.connection(argName="sqlDB", alias="COGSdb") @udf.function() async def runAllCogsCalculations(sqlDB: fn.FabricSqlConnection) -> str:While for some reason this does not cause issues in testing, it leads to all functions defined before the last instance of the line to be unavailable when published, without producing a clear error as to why.
Luckily, the solution is very simple: just remove all but the first use of "udf = fn.UserDataFunctions()" without changing anything else, and the issue should be resolved.
Hopefully this helps someone who's facing the same issue. I also made sure to report the problem somehow bypassing testing to microsoft, and I hope in the future there will be a proper error to prevent this.
Hi aplia,
This is interesting.
Just to confirm a few things, have you check capacity metrics to ensure that your capacity has returned to a normal state? WIth how capacity smoothing works, sometimes it will stay in a throttled state until well after the task that caused the throttling has ended.
Outside of that, are you the user that is trying to click the button in the report? Are permissions applied correctly if you are not that user?
If your capacity is good, and permissions are good, then I've never seen this behaviour before.
THe last troubleshooting step I would recommend is to re-publish the UDF and see if that changes anything, if not, this sounds like a bug somewhere and a ticket to Microsoft may be needed.
Hi aplia,
Since the same UDF fails from both the Power BI report and a pipeline, I would first check whether the published function is healthy before troubleshooting either caller separately.
Fabric User Data Functions have two different execution paths:
- Test runs the function in the development/test session.
- Run invokes the published version of the function.
Microsoft recommends using Run mode specifically to verify that the published function works for users with Execute permission.
So my first test would be:
- Open the User Data Functions item.
- Publish the latest version again.
- Switch to Run mode, not Test.
- Invoke the same function with the same parameters.
If Run mode also fails, then Power BI and the pipeline are probably only surfacing the same underlying published-function problem.
I would then check the historical invocation logs. Microsoft exposes separate logs for published function invocations, which should help show whether the request reaches the function runtime and where it fails.
The 404 in the pipeline response is also interesting. I would not read that as an HTTP endpoint problem immediately, but it does make me want to verify that the pipeline activity is pointing at the current published UDF item and function rather than stale metadata from an earlier version.
If republishing fixes Run mode, I would then reselect the UDF in the pipeline activity and the Power BI Data Function button so both callers pick up the current published function metadata.
Microsoft does support invoking User Data Functions directly from Fabric pipelines, so if the same published function fails there as well as in Power BI, I would focus on the UDF publication/invocation layer first rather than capacity throttling.
If Run mode succeeds but both external callers still fail, then permissions and caller-specific configuration become the next place I would look.
