Intermittent ERR_HTTP2_PROTOCOL_ERROR causing "Failed to fetch" across multiple IDX endpoints in Sign-In Widget

[kalingabandara-yl]

Describe the bug

Bug Description

We are experiencing intermittent HTTP/2 transport-level failures during the Okta IDX authentication flow when using the Okta Sign-In Widget.

The issue is not limited to a single endpoint. We have observed the same error occurring on multiple IDX calls, including:

• POST /idp/idx/identify: When entering the username
• POST /idp/idx/challenge/answer: When entering the passsword
• POST /idp/idx/challenge/poll: When following forgot password flow as in https://github.com/okta/okta-signin-widget/issues/3935

When the issue occurs, Chrome reports:

• net::ERR_HTTP2_PROTOCOL_ERROR

The Sign-In Widget then displays a generic "Failed to fetch" error.

Importantly, no HTTP status code (4xx/5xx) is returned. The failure appears to occur before a valid HTTP response is received, suggesting the issue happens at the HTTP/2 transport layer rather than the application layer.

The issue is intermittent and resolves on page refresh or retry.

Key Observations

1. The issue occurs across multiple IDX endpoints (identify, challenge/poll, challenge/answer).
2. The failure happens before any HTTP status code is received.
3. The issue is intermittent and not consistently reproducible.
4. Disabling HTTP/2 in Chrome (via --disable-http2) completely eliminates the issue.
5. When HTTP/2 is disabled, the flow works reliably without any failures.

Based on this behavior, it appears that the issue may be related to HTTP/2 stream handling or connection reuse behavior affecting IDX endpoints.

Reproduction Steps

Reproduction Steps

1. Open application login page using Okta Sign-In Widget.
2. Proceed through the authentication flow.
3. Observe network requests to: /idp/idx/identify /idp/idx/challenge/poll /idp/idx/challenge/answer
4. Intermittently, one of these requests fails with: net::ERR_HTTP2_PROTOCOL_ERROR
5. Widget displays: "Failed to fetch"
6. Refreshing the page or retrying resolves the issue.

Repeated login attempts increase the likelihood of reproducing the issue.

SDK Versions

System:
OS: Linux 6.14 Ubuntu 24.04.2 LTS 24.04.2 LTS (Noble Numbat)
CPU: (12) x64 13th Gen Intel(R) Core(TM) i7-1355U
Memory: 14.64 GB / 30.99 GB
Container: Yes
Shell: 5.2.21 - /bin/bash
Binaries:
Node: 24.4.1 - /home/user/.nvm/versions/node/v24.4.1/bin/node
Yarn: 1.22.22 - /home/user/.nvm/versions/node/v24.4.1/bin/yarn
npm: 11.4.2 - /home/user/.nvm/versions/node/v24.4.1/bin/npm
Browsers:
Chrome: 145.0.7632.45

Additional Information

Since disabling HTTP/2 removes the issue entirely, this suggests the problem may be related to HTTP/2 stream resets or connection reuse behavior at the edge.

We would appreciate assistance in:

• Determining whether there are known HTTP/2 stream handling issues affecting IDX endpoints
• Verifying if stream resets or connection-level GOAWAY frames are being issued for these requests
• Advising on recommended mitigation strategies

Following is a snapshot of the network tab when the error happens.

Here is a snapshot from netlog-viewer for the saved network logs of the failed event.

###Troubleshooting Performed

To rule out client-side factors, we have also:

• Updated Google Chrome to the latest stable version
• Reproduced the issue in Incognito mode
• Disabled and removed all browser extensions
• Tested in multiple Chromium-based browsers (e.g., Chrome, Edge)
• Verified that the issue does not occur in Mozilla Firefox
• Confirmed that disabling HTTP/2 eliminates the issue completely

Despite these steps, the issue continues to occur intermittently in Chromium-based browsers when HTTP/2 is enabled.