Sorry I've gone through every stack overflow question of this exact same error and no one has definitely provided an answer to this.
My production app only sometimes gives this error per my reporting service, so I am thinking two things:
Internet connection blipped out which it often does
There's some React Native timeout or under the hood machinery that cancels the attempt if the server hasn't returned anything.
To clarify:
fetch().then((response) => {
// Server returned something, even 500
}).catch((e) => {
// Server returned nothing OR internet connection bad?
// RN doesn't care to share why, just "I couldn't fetch"
});
since the fetch function is a javascript function, let's see what MDN docs say :
A fetch() promise will reject with a TypeError when a network error is encountered or CORS is misconfigured on the server side, although this usually means permission issues or similar — a 404 does not constitute a network error, for example.
Related
I have a redux driven app that’s been working great. But I recently got an error when I tried to read some properties from a state object in my jsx. The state object only has ~30 fields, not big at all.
Here's the error:
PayloadTooLargeError: request entity too large
at readStream (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/raw-body/index.js:155:17)
at getRawBody (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/raw-body/index.js:108:12)
at read (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/body-parser/lib/read.js:77:3)
at jsonParser (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/body-parser/lib/types/json.js:135:5)
at call (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/connect/index.js:239:7)
at next (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/connect/index.js:183:5)
at remoteDevtoolsCorsMiddleware (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/#expo/dev-server/src/middleware/remoteDevtoolsCorsMiddleware.ts:31:3)
at call (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/connect/index.js:239:7)
at next (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/connect/index.js:183:5)
at serveStatic (/Users/a/.nvm/versions/node/v16.14.2/lib/node_modules/expo-cli/node_modules/serve-static/index.js:75:16)
From what I saw on stack overflow, this error is associated with json size limits in the body-parser node module… and as I can see from my error, body-parser is used by the connect node module which acts as expo’s HTTP server.
Related stackoverflow questions all seem to be for express.js (like this one node.js - Getting error PayloadTooLargeError: request entity too large in case of Using express.Router() Post call - Stack Overflow).
What’s causing this in expo? Is it indeed body-parser?
How I can increase the json limits in an expo app like others are doing in express?
I have the following code...
async function GetFirstAssessment() {
try {
const response = await axios.get('http://192.168.254.10/App/GetFirstAssessment/');
return response.data;
} catch (error) {
alert('error: ' + error);
console.error(error);
}
};
It's been working fine for some time, but suddenly it no longer works and eventually times out. Or I don't even know if it "times out" since I believe the default timeout for axios is 0 but eventually it does error with the message "Error: Network Error". I've also added a picture of the stack trace but I don't think it's helpful.
I can put the url in a browser and it returns the json I'm expecting, so the problem is definitely not on the server side. I am testing from an android device connected via usb and developing with cli (not expo).
If there is any other information I can provide please let me know... not sure what to do next because this really makes no sense. I would wonder if it was a security issue except that it was working perfectly earlier. Also I have updated some other code that calls this, but even after reverting I still have the same problem... and seeing as how it is making it to the catch, I don't see how any other code could be affecting this.
I did just install the standalone react native debugger. I believe it has worked since I installed it, though I'm not 100% certain on that. Still doesn't work after closing it.
I set a break point in the server code on the first line of the api method, but it doesn't get hit. Not sure how to troubleshoot further up the chain though. I also just thought to check fiddler and it doesn't show any request coming in, though I honestly don't know if it should normally or not.
currently i develop an Ionic2 application which commuicates with a Firebase database. While updating a node sometimes it works and sometimes it doesn't.
So i tired to handle the error with the following code:
this.db.list("/Events/" + this.eventID+ "/teilnehmer").push(this.userID)
.then(resolve => {
console.log('success');
}, reject => {
console.log('error');
})
.catch(reject => {
console.log('catch');
});
But even if i disconnect my internet connection there is no error thrown.
Does someone of you know how i could handle an error if the push was not successful?
I had the same situation that push does not return promises sometime, so i raised issue on github FirebaseListObservable push() takes too long to add but unfortunately it was not resolved, I contacted firebase support through email, the support team reviewed my issue and checked the code i sent, and replied there is nothing to do in the code , and advised me to clear the phone's storage cache, i did the same and issue got resolved,
here is the mail from firebase support
Hi xxxx,
I suggest that you try clearing your phone's cache before proceeding
again, its memory might be too high. To do this, go to: Settings ->
Storage -> Cached Data. Select it then then choose ok (for clearing
the cache). Also please check this the same issue raised on Github
and answered by one of our engineers.
If the issue persists after trying the proposed suggestions, please
get back to me with a minimal and runnable code that we can use to
simulate this, possibly a plunkr or jsfiddle code, or a from the
scratch code that can demonstrate the issue.
Regards, xxxx
If you would like to handle this you could consider setting a timeout because the Promise will just stay in 'pending' if Firebase doesn't return anything and resolve, reject / catch will never be triggered.
You could do this for example with Promise.race(): Example Promise timeout with Promise.race() also check this thread: More Examples
What is the difference between throw new Error and using Meteor.Error()? Is it simply that throw new Error will not be shown to the client, only on the server (the client will get a 500 Internal server error); and Meteor.Error will be sent to the client.
Are there any more differences? E.g. Does one break out of Fibers, stops downstream code?
The main thing with Meteor.Error is like you mentioned
A full stack trace (may not be given by Error always)
Possibility to send the error down to the client, in a limited non revealing form.
Hide the error from the server in certain cases (if its thrown in a method or publish method, and from hooks such as Accounts.onLoginAttempt)
The objects inside are EJSON serialised so a variety of data can be sent down to the client
When a Meteor.Error is thrown, because of the EJSON serialisation you get a bit more information on the server side.
Meteor displays the errors better.
Often you can get [Object object] as the reason to be displayed from ordinary errors when they come from ordinary Errors, from Meteor.wrapAsync
Theres not much else that's different, Meteor.Error is a a subclass of Error with the above changes.
So they'll both stop downstream code. When it comes to Fibers, if the ordinary one is thrown out of a Fiber in any way its likely to stop your app (on the server side & not in a method, startup, Meteor.setInterval, publish, etc)
Its definition is also quite small: https://github.com/meteor/meteor/blob/devel/packages/meteor/errors.js
I do asynchronous requests in LoadState method of a certain Page. I use HttpClient to make a request and I expect the splashscreen to go away while I await the result.
If I am not connected to any networks, the splashscreen immediately goes away and I get a blank page because the request obviously didn't happen.
But if I am connected to a network but have connectivity issues (for example, I set a wrong IP address) it seems to start a request and just block.
My expectation was that the HttpClient would realize that it cannot send a request and either throw an exception or just return something.
I managed to solve the issue of blocking by setting a timeout of around 800 milliseconds, but now it doesn't work properly when the Internet connection is ok. Is this the best solution, should I be setting the timeout at all? What is the timeout that's appropriate which would enable me to differentiate between an indefinitely blocking call and a proper call that's just on a slower network?
I could perhaps check for Internet connectivity before each request, but that sounds like an unpredictable solution...
EDIT: Now, it's really interesting. I have tried again, and it blocks at this point:
var rd = await httpClient.SendAsync(requestMsg);
If I use Task.Run() as suggested in the comments and get a new Thread, then it's always fine.
BUT it's also fine without Task.Run() if there is no Internet access but the network access is not "Limited" (it says that the IPv4 connectivity is "Internet access" although I cannot open a single website in a browser and no data is returned from the web service. It just throws System.Net.Http.HttpRequestException which was something I was expecting in the first place) Only blocks when the network connection is Limited.
What if instead of setting a timeout, you checked the connection status using
public static bool IsConnected
{
get
{
return NetworkInformation.GetInternetConnectionProfile() != null;
}
}
This way if IsConnected, then you make the call; otherwise, ignore it.
I'm not sure if you are running this in App.xaml.cs? I've found requests made in that class can be fickle and it may be best to move the functionality to an extended splash screen to ensure the application makes it all the way through the activation process.
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh868191(v=win.10).aspx