Forum Discussion
User data function invocation failed (but works in testing)
- 15 days ago
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,
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.