GetIdCommand and fromCognitoIdentityPool do not provide information needed to diagnose problems when they fail

[EmperorArthur]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

Attempting to obtain Cognito Credentials via fromCognitoIdentityPool or the underlying GetIdCommand fails when using the default FetchRequestHandler. Unfortunately, the error generated by AWS provides zero help in identifying what went wrong.

Edit: Specifically the error response is a generic 400, with no details about what is missing or incorrect.

Regression Issue

• Select this option if this issue appears to be a regression.

SDK version number

@aws-sdk/package-name@version, ...

Which JavaScript Runtime is this issue in?

Browser

Details of the browser/Node.js/ReactNative version

tauri 2.8.5 on both Windows and Linux

Reproduction Steps

const region = ...;
const poolId = ...;

const credentials = fromCognitoIdentityPool({
            clientConfig: {
                region: region,
            },
            identityPoolId: poolId,
        });
const pollyClient = new PollyClient({
                region: region,
                credentials: credentials,
            });

Observed Behavior

Receive the following error:

{
  "$fault":"client",
  "$metadata":{
    "httpStatusCode":400,
    "requestId":"655cb486-48c5-4486-9e00-5a56c95f3de9",
    "attempts":1,
    "totalRetryDelay":0
  },
  "name":"BadRequest",
  "code":"BadRequest",
  "message":"The server did not understand the operation that was requested.",
  "type":"client"
}

Expected Behavior

Edit:

Receive an error response which identifies what portion of the request is missing or malformed.

Additional Information/Context

See Uhuh/tts-helper#53

[aBurmeseDev]

Hi @EmperorArthur - thanks for reporting this and for the thorough investigation.

After looking into this, I believe this is a compatibility issue with Tauri's webview Fetch API implementation rather than a bug in the SDK. The SDK's FetchHttpHandler constructs requests per the standard Fetch API spec, and this works correctly in standard browsers. Tauri's webview appears to handle request headers or body encoding differently, which causes the Cognito service to reject the request.

The XhrHttpHandler works in your case because it explicitly omits certain headers (like Content-Length) and lets the runtime compute them from the actual transmitted body, which sidesteps Tauri's non-standard behavior.

Since the SDK is functioning correctly per spec and this issue is specific to Tauri's Fetch implementation, I'd recommend reporting this upstream to the Tauri project as their Fetch API behavior diverges from the standard.

Hope that helps!

[EmperorArthur]

Hello,

Thank you for the response. I believe closing this issue as 3rd party is not appropriate. I have updated the name and description to clarify the problem and the requested change.

Because the error message was so generic, it took me days to identify the problem. This is after the original developer gave up and assumed the AWS service was broken!

Given the 400 response, I spent significant amounts of time assuming I had misconfigured something in AWS.

[aBurmeseDev]

Hi @EmperorArthur, thanks for the follow-up.

Completely understand the frustration on a generic 400, however, the error message you see comes directly from the Cognito service response which the SDK deserializes and surfaces whatever the service returns. Unfortunately, we can't improve service-side error messages from within the SDK. Though you could reach out to Cognito directly via AWS Support.

For what it's worth, the underlying issue is that Tauri's fetch implementation doesn't treat Content-Length as a forbidden
header the way standard browsers do. The SDK computes and sets Content-Length, standard browsers silently ignore it (per spec) and compute it themselves, but Tauri appears to honor it which can cause a mismatch if the body is re-encoded. This is why XhrHttpHandler works where it explicitly omits Content-Length from the request headers.

If you'd like a more targeted workaround without switching to XHR entirely, you could use middleware to strip the Content-Length header before it reaches the fetch call:

client.middlewareStack.add(
  (next) => async (args) => {
    delete args.request.headers["content-length"];
    return next(args);
  },
  { step: "finalizeRequest", name: "stripContentLength", override: true }
);

I'd still recommend reporting the non-spec-compliant fetch behavior to the Tauri. Regarding the error messaging concern, that feedback is best directed to the AWS Cognito team since they control the error response format. Let me know if you have any further questions!