Forum Discussion
Missing status values in the C# client model
The C# client model for the pipeline run status (first screenshot) for the Get Item Job Instance endpoint doesn't match the status values in the documentation — most of the values from documentation are missing and there's a `Succeeded` value that doesn't exist in the documentation.
Is it possible to get values that match the documentation without using string representation of the C# client model property?
And if not then what's the point of having a structure that doesn't match the documentation? Maybe just make it a string then?
Looks like the issue is resolved in the latest client version (2.14.0 at the moment)
9 Replies
Hi Konstantin_K
Thank you for reaching out to the Microsoft Fabric community forum.The mismatch occurs because two different status systems are involved. The Get Item Job Instance endpoint returns job‑scheduler statuses such as NotStarted, InProgress, Completed, Failed, and Cancelled (with more possibly added over time), which match the REST documentation.
The .NET SDK type you see in IntelliSense Microsoft.Fabric.Api.Core.Models.Status comes from the long‑running operation (LRO) model and uses a smaller set of outcome‑based values like Running, Succeeded, and Failed. These LRO values are not designed to match Job Scheduler statuses directly.
Because these domains serve different purposes, the SDK’s LRO enum cannot provide the documented job‑scheduler states. To obtain the correct values, read the status field directly from the Job Scheduler response and map it yourself (for example, with a custom ItemJobStatus enum including an Unknown fallback).
If your application also uses LRO or operations/* endpoints, handle those statuses separately and translate them if needed. This keeps your implementation aligned with the REST API and ensures forward compatibility as new job statuses are introduced.
If you have further questions, feel free to ask and we’ll be happy to help.Best regards,
Microsoft Fabric Community Support Team.
> The .NET SDK type you see in IntelliSense Microsoft.Fabric.Api.Core.Models.Status comes from the long‑running operation (LRO) model and uses a smaller set of outcome‑based values like Running, Succeeded, and Failed. These LRO values are not designed to match Job Scheduler statuses directly.
Is that mentioned somewhere in the documentation? Or how to know about that?
Everything that you described looks like internals of the implementation. I don't see a reason why anybody as a consumer of the SDK should know about these internals and why they are exposed to everybody.
I basically want the client to follow the documentation and provided contract.>To obtain the correct values, read the status field directly from the Job Scheduler response and map it yourself
Why every consumer has to implement own mapping from some undocumented internal model instead of doing that once in the SDK?
Why can't an Enum with declared values be used in the SDK?
Is that guaranteed that this LRO model will not be changed?
Hi Konstantin_K
I understand the confusion, because two different, publicly documented status systems are involved. The Get Item Job Instance API returns the job-scheduler status (NotStarted, InProgress, Completed, Failed, Cancelled, etc.) and its schema explicitly notes that new statuses may be added over time. Separately, Fabric exposes Long-Running Operation (LRO) endpoints under operations, which use a different, generic status set such as Running and Succeeded. These LRO statuses are documented, but they are not meant to match job instance statuses one-to-one.
The .NET type Microsoft.Fabric.Api.Core.Models.Status corresponds to this LRO model, not the Job Scheduler contract. Because job status is an open-ended set, the SDK intentionally avoids a closed enum for it, doing so would cause breaking changes whenever the service introduces a new value. This follows standard .NET/Azure SDK guidance to avoid enums for evolving service-defined values.
If you need the exact job statuses shown in the REST docs, the correct approach is to read the status field directly from the Job Scheduler response and map it locally (with an Unknown fallback). LRO statuses should be handled separately if you also poll operations. The confusion around this distinction is fair and raising a docs/SDK improvement request through Fabric Ideas - Microsoft Fabric Community may help you with this in the long run.
For more details, please refer to the Microsoft official documentation on
Long running operations - Microsoft Fabric REST APIs | Microsoft Learn
Job Scheduler - Get Item Job Instance - REST API (Core) | Microsoft LearnIf you have any more questions, please let us know and we’ll be happy to help.
Regards,
Microsoft Fabric Community Support Team
Hi Konstantin_K
We have not received a response from you regarding the query and were following up to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Thank You.
Hi Konstantin_K
Just checking in as we haven't received a response to our previous message. Were you able to review the information above? Let us know if you have any additional questions.
Thank You.Looks like the issue is resolved in the latest client version (2.14.0 at the moment)
