You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After locally fixing the input set region issue #249 , I found a interesting bug where when assuming the role, I am able to assume the role, successfully send listbucket request and then when it creates the sqs client and url to use, I get a 400 bad request because the queue name cannot be found for this wsdl.
But after inspecting using fluentd -vv it's clear the issue is that although my fluent.conf sets the SQS queue_name correctly, the SQS client POST request is to / instead of the /accountnumber/queue_name
The region for sqs HOST is also correct. See Image below. The log even shows the right queue name but for somereason didn't form the URL correctly. I have also properly granted my assumedRole access to the SQS queue in us-west-2 but no way to know if it's working since the POST request is incorrect.
The issue does not exist when using a key/secret key to another queue in the same region and the sqs client POST url is correctly formed, seems to be limited to assumeRole scenario
I believe the issue is due to the sqs queue not being in the same account as the assumed role. Is this a requirement? I have granted access to the assumed role to that sqs queue but seems it's a related issue.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
After locally fixing the input set region issue #249 , I found a interesting bug where when assuming the role, I am able to assume the role, successfully send listbucket request and then when it creates the sqs client and url to use, I get a 400 bad request because the queue name cannot be found for this wsdl.

But after inspecting using fluentd -vv it's clear the issue is that although my fluent.conf sets the SQS queue_name correctly, the SQS client POST request is to / instead of the /accountnumber/queue_name
The region for sqs HOST is also correct. See Image below. The log even shows the right queue name but for somereason didn't form the URL correctly. I have also properly granted my assumedRole access to the SQS queue in us-west-2 but no way to know if it's working since the POST request is incorrect.
The issue does not exist when using a key/secret key to another queue in the same region and the sqs client POST url is correctly formed, seems to be limited to assumeRole scenario
I believe the issue is due to the sqs queue not being in the same account as the assumed role. Is this a requirement? I have granted access to the assumed role to that sqs queue but seems it's a related issue.
The text was updated successfully, but these errors were encountered: