Legacy Dev Forum Posts

Amit_Akela | 2023-02-02 16:26:45 UTC | #1

Below is the resource export I am trying to do -

"resource "genesyscloudtfexport" "export" { * directory = "./Users"* * resourcetypes = ["genesysclouduser"]* * includestatefile = true* * exportashcl = true* * logpermissionerrors = true* }"

But getting below error message, please suggest.

╷ │ Error: Failed to get page of users: API Error: 400 - BAD_REQUEST (58bb6f3e-e59d-4443-89e7-ce9597ee4886) │ │ with genesyscloudtfexport.export, │ on export.tf line 1, in resource "genesyscloudtfexport" "export": │ 1: resource "genesyscloudtfexport" "export" {

John_Carnell | 2023-02-02 21:20:30 UTC | #2

Hey Amit,

Thanks for posting. Can you set the sdk_debug=true in the provider and then post the correlation id from the log for the API call that is failing? Also, can you tell me the Genesys Cloud AWS region you are working in? We are going to try to reproduce it in our labs, but if they are something specific to your org that is triggering a defect we will need to look in our logs.

Thanks, John Carnell Director, Developer Engagement

Amit_Akela | 2023-02-03 03:01:53 UTC | #3

Hi John,

I have set the sdk_debug=true, Correlation id : 8931a155-9380-4c81-bf7f-efb0ed798e59.

Region : US-West-2

Thanks, Amit

John_Carnell | 2023-02-07 13:19:00 UTC | #4

Hi Amit,

So I dug into this and what you are running into is a limitation with our internal search cluster. When we do the getAllUsers call there are situations where our user service will shunt the request over to the internal search cluster.

If your OAuth client allows is set up to see multiple divisions or the call also pulls back inactive users the requests flip over to our search cluster. Our search cluster will return 10,000 records back and then return 400 HTTP status codes indicating it is a bad request. They return a 400 because they don't want clients retrying if they sent back a 429.

While this search limitation is documented here, there is no obvious connection back to the user api. Here is what I would do:

1. The limit is a hard limit and can not be changed. Since CX as Code pulls both inactive and active users (per other customer requests) we can not change the functionality of the provider.
2. If you just want to do an export you could set up individual client oauth ids that have visibility to a single division. You could then use the Genesys cloud cli (gc users list -a) and try to pull back the records. As long as the OAuth client id's role is only assigned to a single division you might be able to get beyond this limit, but I can not guarantee you will not run into any issues. Many of our services have carefully documented their rate limits, but the directory service is one of our older services and has nooks and crannies that are not always up to date.
3. I will add some documentation to the CX as Code genesyscloud_user resource to help give people a heads-up of this limitation.

Just out of curiosity. Why are you doing a complete export? Are you trying to migrate users back from a prod back to a dev org.

Thanks, John Carnell Director, Developer Engagement

Amit_Akela | 2023-02-07 11:18:39 UTC | #5

Hi John,

Yes, just wanted to run this on dev org before executing on Prod org.

The above details help, I will try the CLI approach for division specific User export.

Much appreciate your help on this one.

Thanks, Amit

system | 2023-03-10 11:19:09 UTC | #6

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.

This post was migrated from the old Developer Forum.

ref: 18242