expo: Network request failed using fetch

šŸ› Bug Report

Summary of Issue

Network request failed
- node_modules/whatwg-fetch/dist/fetch.umd.js:527:17 in setTimeout$argument_0
- node_modules/react-native/Libraries/Core/Timers/JSTimers.js:130:14 in _callTimer
- node_modules/react-native/Libraries/Core/Timers/JSTimers.js:383:16 in callTimers
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:416:4 in __callFunction
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:109:6 in __guard$argument_0
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:364:10 in __guard
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:108:4 in callFunctionReturnFlushedQueue
* [native code]:null in callFunctionReturnFlushedQueue

I’ve no idea why but recently no fetching works and I get this error above. It’s so frustrating because I have no clue what the actual problem is. I’ve looked at similar bug reports and many of them say it’s because of https vs http or LAN issues.

But I am using an external API with https so it can’t be that. I am using useSWR but I am pretty sure it has nothing to do with that specific library. It’s either React Native/Expo or some problem with the whatwg-fetch polyfill.

Environment - output of expo diagnostics & the platform(s) you’re targeting

  Expo CLI 3.28.0 environment info:
    System:
      OS: macOS 10.15.7
      Shell: 5.7.1 - /bin/zsh
    Binaries:
      Node: 14.5.0 - ~/.nvm/versions/node/v14.5.0/bin/node
      Yarn: 1.22.10 - /usr/local/bin/yarn
      npm: 6.14.5 - ~/.nvm/versions/node/v14.5.0/bin/npm
    Managers:
      CocoaPods: 1.9.1 - /usr/local/bin/pod
    SDKs:
      iOS SDK:
        Platforms: iOS 14.1, DriverKit 19.0, macOS 10.15, tvOS 14.0, watchOS 7.0
    IDEs:
      Android Studio: 4.1 AI-201.8743.12.41.6858069
      Xcode: 12.1/12A7403 - /usr/bin/xcodebuild
    npmPackages:
      expo: ~39.0.2 => 39.0.3 
      react: 16.13.1 => 16.13.1 
      react-dom: 16.13.1 => 16.13.1 
      react-native: ~0.63.3 => 0.63.3 
      react-native-web: ~0.13.12 => 0.13.18 
    npmGlobalPackages:
      expo-cli: 3.28.0
    Expo Workflow: bare

Reproducible Demo

This one is actually difficult to demo as I don’t know how to reproduce.

Steps to Reproduce

I am using useSWR if that’s any good info. Other than that I’ve honestly no idea. I just am using fetch.

  fetch(url, {
    headers: {
      Accept: 'application/json',
      Authorization: `Bearer ${token}`,
    },
  }).then((res) => res.json())

Expected Behavior vs Actual Behavior

I shouldn’t get a Network request failed error.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 19 (2 by maintainers)

Commits related to this issue

Most upvoted comments

I found that by setting the ā€œContent-Typeā€ header on the fetch request (in my case to ā€œapplication/jsonā€) fixes this issue.

fetch('https://some.url/something', {
      method: 'POST',
      headers: {
        Accept: 'application/json',
        'Content-Type': 'application/json',
        ...authorizationHeaders,
      },
      body: JSON.stringify({
        'something': 'hi',
        'something_else': 'hey',
      })
    })
    .then((response) => response.json())
    .then((json) => {
        console.log(json);
    })

I have the same issue … It was working previously … Here my code :

formData.append('files[]', {
        uri: this.state.picture, 			// this is the path to your file. see Expo ImagePicker or React Native ImagePicker
        type: `image/jpeg`,  // example: image/jpg
        name: `upload.jpg`    // example: upload.jpg
});

          fetch(GLOBAL.domain + '/file/upload/' + json.referral._key + '/datasets/pictures', {
            method: 'POST',
            headers: {
              'Accept': 'application/json',
              'Content-Type': 'multipart/form-data',
              'X-Session-Id': self.props.route.params.token
            },
            body: formData
          })
          .then((response) => response.json())
          .then((json_picture) => {
            console.log(json_picture)
            self.setState({ uploading: false, account_created: true })
          })
          .catch((error) => {
            console.error(error);
          });

and here the result

Network request failed
at node_modules/whatwg-fetch/dist/fetch.umd.js:535:17 in setTimeout$argument_0
at [native code]:null in callFunctionReturnFlushedQueue

@byCedric You’re so nice. Thanks for the quick response. My issue is fixed now. All I did was to restart my computer and reset expo caching. I’ve have honestly no idea what would cause this.

Me too. I installed a new expo project to test by using expo init but I’ve got the same error. there is my App.js code :

import { StatusBar } from 'expo-status-bar';
import React from 'react';
import { StyleSheet, Text, View } from 'react-native';

export default function App() {
  fetch("192.168.1.53:5000").then(()=>{console.log("success");}).catch((err)=>{console.log(err);})
  return (
    <View style={styles.container}>
      <Text>Network request test</Text>
      <StatusBar style="auto" />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

here is the result of promise catch :

Network request failed
at node_modules/whatwg-fetch/dist/fetch.umd.js:535:17 in setTimeout$argument_0
at [native code]:null in callFunctionReturnFlushedQueue

Hi @nimabrownlee! It’s unfortunate that the error stack isn’t helpful here. I’ve looked around in the React Native repository too, and it looks like it might be related to a regression issue from whatwg-fetch. It seems that the Content-Type header sometimes isn’t sent with the request, which causes the request to fail randomly (but only in React Native).

These threads might help:

For now, I’ll mark this issue as upstream. It seems like this is coming from React Native itself. If you are able to, could you create a small example where this consistently happens? That would be extremely helpful for us, so we can focus on fixing this. You should be able to use any public API, like https://httpbin.org/anything, with fake bearer tokens.

Hope this helps!

For my case, the 'Content-Type': 'application/json' bit worked. What the heck??