Problem creating workload item when logged in as non-admin

[box-turtle]

We just started having an issue in our dev environment where non-admin users are not able to create our 3rd party workload items. The error we receive from the create item call POST to

https://wabi-us-north-central-j-primary-redirect.analysis.windows.net/metadata/workspaces/58326055-de45-4e9c-80ac-689c94c96a8f/artifacts


Activityid: 95c4d20d-2e34-4825-8c36-ea5ec25bca71
Requestid: 538afd12-07e1-1fdc-8ae1-a43a69487759

is not very informative - we get a 404 with this response body:

{
    "error": {
        "code": "PriorityPlacementCoreServiceNotFound",
        "pbi.error": {
            "code": "PriorityPlacementCoreServiceNotFound",
            "parameters": {},
            "details": [],
            "exceptionCulprit": 1
        }
    }
}

I CAN create an item when logged in as a Fabric admin user, it's only normal users who have this difficulty. The strange thing is that they did not have a problem with this last week.

This only affects our 3rd party workload - users are able to create regular synapse notebooks and other items in that capacity.

If I am logged in as a normal user and navigate to the workspace where I normally create items, and then check the workspace settings/ license info, it tells me the workspace is assigned to a Fabric capacity, but it says This workspace is configured to use a capacity you don't have access to

[dhrumil83]

I am getting a similar error creating new items.
Url: https://wabi-west-us-redirect.analysis.windows.net/metadata/workspaces/4e313df9-54aa-4510-a864-bcc9825793b5/artifacts

{
    "error": {
        "code": "PriorityPlacementCoreServiceNotFound",
        "pbi.error": {
            "code": "PriorityPlacementCoreServiceNotFound",
            "parameters": {},
            "details": [],
            "exceptionCulprit": 1
        }
    }
}

[box-turtle]

Just to update further, now I can't create an item on the original capacity using dev mode/devgateway.exe - I get a 500 error trying to create or load items.

I'm basically dead in the water.

Request id for create call using dev mode/devgateway in the original capacity:

78f0818f-e3c5-99ed-f85c-6d530d6b84d3

[ramizsha]

@box-turtle two points:

1. Regarding this request Id "d8183da3-6af7-6bb6-2b66-cabb24863d17", I see that the request to your workload returns 404, the request we send is a post request that looks like this: /workspaces//items//. can you validate that this url is reachable?
2. Regarding this request Id "78f0818f-e3c5-99ed-f85c-6d530d6b84d3", I see that in this flow you are working with the same capacity used in the above request ("d8183da3-6af7-6bb6-2b66-cabb24863d17").
   Please make sure to switch to a workspace that is assigned to the same capacity you registered your dev instance on.

[box-turtle]

@box-turtle two points:

1. Regarding this request Id "d8183da3-6af7-6bb6-2b66-cabb24863d17", I see that the request to your workload returns 404, the request we send is a post request that looks like this: /workspaces//items//. can you validate that this url is reachable?

Request with id d8183da3-6af7-6bb6-2b66-cabb24863d17 was the one where I used a workspace with a newly created capacity and it returned a 500 error, not a 404.

2. Regarding this request Id "78f0818f-e3c5-99ed-f85c-6d530d6b84d3", I see that in this flow you are working with the same capacity used in the above request ("d8183da3-6af7-6bb6-2b66-cabb24863d17").
   Please make sure to switch to a workspace that is assigned to the same capacity you registered your dev instance on.

I thought I had switched to a workspace assigned to the "old" capacity for this test (d8183da3-6af7-6bb6-2b66-cabb24863d17), but I must have made a mistake. I will retest the devgateway scenario.

[ramizsha]

@box-turtle two points:

1. Regarding this request Id "d8183da3-6af7-6bb6-2b66-cabb24863d17", I see that the request to your workload returns 404, the request we send is a post request that looks like this: /workspaces//items//. can you validate that this url is reachable?

Request with id d8183da3-6af7-6bb6-2b66-cabb24863d17 was the one where I used a workspace with a newly created capacity and it returned a 500 error, not a 404.

I understand, what I'm saying is that the request to your workload from Fabric returned 404 (In control plane APIs Fabric calls your workload).

2. Regarding this request Id "78f0818f-e3c5-99ed-f85c-6d530d6b84d3", I see that in this flow you are working with the same capacity used in the above request ("d8183da3-6af7-6bb6-2b66-cabb24863d17").
   Please make sure to switch to a workspace that is assigned to the same capacity you registered your dev instance on.

I thought I had switched to a workspace assigned to the "old" capacity for this test (d8183da3-6af7-6bb6-2b66-cabb24863d17), but I must have made a mistake. I will retest the devgateway scenario.

[box-turtle]

ah - I see. Thank you. Let me do more checking on my end.

[box-turtle]

OK - we had a bad deployment of our BE code. Issues seem resolved now.

Thanks for all the help.

[dhrumil83]

@dhrumil83 can you please provide a requestId so I can take a look at the issue from my end? you can find it in the response headers of the https call.

I changed a few admin settings and uploaded a new nuget file, and the error went away.
Not sure what was it, but everything seems to work now.