Forum Discussion
Missing status values in the C# client model
Looks like the issue is resolved in the latest client version (2.14.0 at the moment)
> 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?
Community SupportHi 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 Learn
If you have any more questions, please let us know and we’ll be happy to help.
Regards,
Microsoft Fabric Community Support Team
> The .NET type Microsoft.Fabric.Api.Core.Models.Status corresponds to this LRO model, not the Job Scheduler contract.
Why Microsoft.Fabric.Api.Core.Models.Status is returned in the Job Scheduler response then?
It shouldn't be marked as solved. It's not.
The SDK model doesn't match the official documentation.
It just uses another not mentioned in the documention model in the response.
Saying that it's OK is wrong.
MS support is very bad, annoying and a waste of time. Especially for Fabric support behind the paywall.
I found a bug for you, you have all the necessary information, feel free to proceed with opening internal issues yourself.
- v-karpurapud
Hi Konstantin_K
To clarify, GetItemJobInstanceAsync returns a Job Scheduler response, not an LRO operation. The reason you see Microsoft.Fabric.Api.Core.Models.Status is that the Fabric SDK uses a shared Status type across multiple API areas, including both Job Scheduler and LRO-related endpoints. This is a common SDK abstraction rather than an indication that the response follows the LRO model.
Your observation about the mismatch with the REST documentation is valid. The SDK status type does not directly mirror the job-status values listed in REST, and currently the SDK does not expose a separate job-specific status model. If closer alignment is important, as suggested earlier submitting feedback through the Fabric Ideas forum Fabric Ideas - Microsoft Fabric Community would allow the product team to consider clearer documentation or a dedicated job-status type in a future update.
Regards,
Microsoft Fabric Community Support Team.
- v-karpurapud
Hi Konstantin_K
Could you please confirm if you've submitted this as an idea in the Ideas Forum? If so, sharing the link here would be helpful for other community members who may have similar feedback.
Thank you for being part of the Microsoft Fabric Community.