I am getting a 500 error when attempting to use the

POST /api/rest/2.0/vcs/git/commits/deploy

API to deploy my TS objects from source control when using a .NET HttpClient. We use this HttpClient to automate the deploy process using Github actions. I get the 500 error whether I use

VALIDATE_ONLY

or

PARTIAL

. 500 > {"error":{"message":{"debug":{"code":13000,"incident_id_guid":"e5cf314e-45dc-446d-8055-4a963de80eee","debug":"Index: 1, Size: 1"}}}} Working with TS support, they were able to find the deploy logs that contain the issue with the objects that couldn't be deployed. However, if I run the same API using the Playground or even Postman, I am able to get a 200 response with the actual warnings/errors that were a part of the deployment. The request I am sending from my code is identical

{
  "branch_name": "pfload",
  "deploy_type": "FULL",
  "deploy_policy": "VALIDATE_ONLY"
}

The only thing I can assume is that this is related in some way to a header value? Here's what my code looks like

builder.Services.AddHttpClient("thoughtspot", client =>
            {
                client.BaseAddress = new Uri(thoughtspotConfig.InstanceUrl);
                client.DefaultRequestHeaders.Add("Accept", "application/json");
                client.DefaultRequestHeaders.Add("User-Agent", "payscale-httpclient");
            });
...
            _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", bearerToken);
            var json = {
  "branch_name": "pfload",
  "deploy_type": "FULL",
  "deploy_policy": "VALIDATE_ONLY"
};
            var response = await _httpClient.PostAsync("api/rest/2.0/vcs/git/commits/deploy", new StringContent(json, Encoding.UTF8, "application/json"));
            var content = await response.Content.ReadAsStringAsync();
            // here I get  the response is not successful 500 error

Any ideas what could be causing this different in behavior between user agents?

Do you get the same error everytime you run this command? Also what was the error cause in the logs that were shared by TS support?

They didn't share the logs but mentioned to me that they saw the validation warnings/errors that the API should have been returned but as far as I know nothing that explained the 500 error. There was also an "object not found" error potentially but not sure of the specifics.

I see. Are you still getting an error? It might be possible that some resources were not present in the system and hence you were getting a 500. I see that the error is

Error while deploying changes : Index: 1, Size: 1
java.util.Collections$SingletonList.get(Collections.java:4817)
com.thoughtspot.callosum.edoc.ImportEPack.processResponseForRelationshipImport(ImportEPack.java:2596)
com.thoughtspot.callosum.edoc.ImportEPack.translateResponseToProto(ImportEPack.java:2496)
com.thoughtspot.callosum.edoc.ImportEPack.makeMetadataChanges(ImportEPack.java:1381)

This looks like an error in the payload from git. Can you follow up with support to get to the relevant team and give this incident id?

Thanks! I think the support rep is monitoring this post as well. I was able to reproduce the issue in PostMAN without using custom code. It appears that the difference is the user I use to run the deployment API. I'm an admin and with my credentials I do get proper responses like I would expect. However, when I use the credentials from the application user, I am getting a 500 error instead. The application user is configured in a group that was granted the "Administrator" role though I'm not sure if I need to select something more specific.

@srikanth.jandhyala can you help here

Looks like some issue when using non admin user. Will check and get back @shikharts_67242

Hey @srikanth.jandhyala . Thanks! This turned out to be a permissions issue with the existing tables. I used my credentials to run the 1st deployment. As a result, the tables were invisible to the application user because tables created by org admins aren't automatically visible to other admins. Sharing the tables/worksheets with the appropriate group seems to have fixed this problem so now I'm able to see the deployment warnings/errors without getting a 500 error.