Repository navigation
AbortSignal/AbortController doesn't work #50015
Copy link
Copy link
Open
Labels
Needs: AttentionIssues where the author has responded to feedback.Issues where the author has responded to feedback.Needs: ReproThis issue could be improved with a clear list of steps to reproduce the issue.This issue could be improved with a clear list of steps to reproduce the issue.Newer Patch Available
Description
Description
- AbortController / AbortSignal are used in javascript to cancel a request started with
fetch, or any other async task that should be cancellable (docs here) - In react native, there are several issues with these APIs:
- DOMException, which is thrown when AbortController is used, doesn't actually exist as a type
- Calling abortController.abort() doesn't actually have any effect, and abortSignal.reason is undefined.
- abortSignal.throwIfAborted() doesn't exist as a function
- I haven't fully verified this, but it looks like AbortController doesn't actually fully abort
fetchrequests.
Steps to reproduce
- Use javascript AbortController the way it's documented here
React Native Version
0.76.1
Affected Platforms
Runtime - Android, Runtime - iOS
Output of npx @react-native-community/cli info
System:
OS: macOS 15.3.1
CPU: (14) arm64 Apple M4 Max
Memory: 175.34 MB / 36.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 22.14.0
path: ~/.nvm/versions/node/v22.14.0/bin/node
Yarn:
version: 1.22.22
path: ~/.nvm/versions/node/v22.14.0/bin/yarn
npm:
version: 10.9.2
path: ~/.nvm/versions/node/v22.14.0/bin/npm
Watchman: Not Found
Managers:
CocoaPods:
version: 1.16.2
path: /Users/luisfinke/.rvm/gems/ruby-3.2.0/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 24.2
- iOS 18.2
- macOS 15.2
- tvOS 18.2
- visionOS 2.2
- watchOS 11.2
Android SDK: Not Found
IDEs:
Android Studio: 2024.2 AI-242.23726.103.2422.13103373
Xcode:
version: 16.2/16C5032a
path: /usr/bin/xcodebuild
Languages:
Java:
version: 23.0.1
path: /usr/bin/javac
Ruby:
version: 3.2.0
path: /Users/luisfinke/.rvm/rubies/ruby-3.2.0/bin/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.3.1
wanted: 18.3.1
react-native:
installed: 0.76.1
wanted: 0.76.1
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: Not found
newArchEnabled: Not found
iOS:
hermesEnabled: Not found
newArchEnabled: Not found
Stacktrace or Logs
N/A
Reproducer
N/A
Screenshots and Videos
No response
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Needs: AttentionIssues where the author has responded to feedback.Issues where the author has responded to feedback.Needs: ReproThis issue could be improved with a clear list of steps to reproduce the issue.This issue could be improved with a clear list of steps to reproduce the issue.Newer Patch Available
Activity
react-native-bot commentedon Mar 13, 2025
Tip
Newer version available: You are on a supported minor version, but it looks like there's a newer patch available - 0.76.7. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.
react-native-bot commentedon Mar 13, 2025
Tip
Newer version available: You are on a supported minor version, but it looks like there's a newer patch available - undefined. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.
react-native-bot commentedon Mar 13, 2025
Warning
Missing reproducer: We could not detect a reproducible example in your issue report. Please provide either:
migueldaipre commentedon Mar 13, 2025
Hey @lufinkey, Can you add the minimum reproducer using our Reproducer Template?
sandeepeven commentedon Mar 17, 2025
Hey @lufinkey, I checked with the Reproducer Template mentioned above Thanks to @migueldaipre . Abort controller worked in my case. You can use the same template to create a reproducible so that it would be easier to target the issue first.
lufinkey commentedon Mar 17, 2025
bensaadi commentedon Apr 4, 2025
Having the same issue when trying to cancel long polling requests.
lufinkey commentedon Apr 4, 2025
vladcos commentedon Apr 16, 2025
Partial temporary solution (for throwIfAborted error) sindresorhus/ky#588 (comment)
ammar-madni commentedon Apr 23, 2025
Repro https://github.com/ammar-madni/abort-signal-abort-controller-react-native-not-implemented-completely
ammar-madni commentedon May 14, 2025
Any updates on this? Would be good to know if there are any plans to implement this.
rafinhaa commentedon Aug 13, 2025
not working in rn 0.79.5 with expo
Update AbortController to more recent polyfill
Update AbortController to more recent polyfill
react-native-bot commentedon Mar 7, 2026
This issue is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.
react-native-bot commentedon Mar 7, 2026
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.
pawarren commentedon Sep 2, 2026
Production impact data for this issue, from a React Native 0.86 app with a realtime sync engine (Rocicorp Zero) whose reconnect loop calls
controller.abort(reason)and then throwssignal.reason:Because the bundled
abort-controller@3.0.0(Libraries/Core/setUpXHR.js) predatessignal.reason, that throw isthrow undefined, which the sync engine classifies as a fatal internal error instead of a retryable one. The result in production: every transient connect failure became a permanent sync outage — plain airplane mode parked sync in ~200ms, our fleet's time-to-connect p90 was 247 seconds with multi-minute permanent stalls, and the engine's entire retry/backoff path was dead code on React Native.We verified the diagnosis by intervention: a local patch adding spec-compliant
abort(reason)/signal.reasonto the bundled polyfill (via pnpm patchedDependencies, covering both dist/.js and dist/.mjs since Metro resolves .mjs first) restored retry end to end on-device with zero permanent stalls across the patched sessions.Minimal repro of the underlying gap, no app required:
Proposed fix: replace or vendor a reason-capable AbortController in RN core, or ship it from Hermes. Waiting on the bundled dependency doesn't seem viable —
abort-controller's last release was 2019 and the project appears unmaintained. A compliant implementation in core would fix this class for every library that follows the spec'd abort-reason contract.