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.
Related
I've recently wanted to get back into programming, and I know that Apollo GraphQL has moved to an asynchronous way to firing up the server per their documentation.
Since switching (and following docs), I can't get my server to fire up, and I don't know why.
When the server attempts to run, it hangs on the execution of .start() on my ApolloServer instance, even though I'm giving it (what I think) are both valid type definitions and resolvers.
The current iteration of my tiny boilerplate project is located here on CodeSandbox.
When I run this code locally, I receive the following error (which isn't shown on CS?):
Argument type {typeDefs: DocumentNode, resolvers: {Query: {hello(): string}}} is not assignable to parameter type ApolloServerExpressConfig
This error is on line 9, where the instance of ApolloServer is created.
I don't know what I'm doing wrong. I was previously using babel-plugin-import-graphql but switched away from that to using a normal JS import w/ the gql tag just to be safe. The problem appears to be with the resolver map, which doesn't make sense:
const resolvers = {
Query: {
hello: () => "world!"
}
};
export default resolvers;
Anyway, thanks in advance! Would love to get this sorted out today. I think if I don't, I'll end up just switching over to using Meteor for full-stack stuff and then use React for the front-end and just not worry about it anymore.
In my application code, there are a lot of calls (like 100+) to the "top object" referring to window.top such as top.$("title") and so forth. Now, I've run into the problem using Cypress to perform end-to-end testing. When trying to log into the application, there are some calls to top.$(...) but the DevTools shows a Uncaught TypeError: top.$ is not a function. This resulted in my team and I discovering that the "top" our application is trying to reach is the Cypress environment itself.
The things I've tried before coming here are:
1) Trying to stub the window.top with the window object referencing our app. This resulted in us being told window.top is a read-only object.
2) Researching if Cypress has some kind of configuration that would smartly redirect calls to top in our code to be the top-most environment within our app. We figured we probably weren't the only ones coming across this issue.
If there were articles, I couldn't find any, so I came to ask if there was a way to do that, or if anyone would know of an alternate solution?
Another solution we considered: Looking into naming window objects so we can reference them by name instead of "window" or "top". If there isn't a way to do what I'm trying to do through Cypress, I think we're willing to do this as a last resort, but hopefully, we don't have to change that, since we're not sure how much of the app it will break upfront.
#Mikkel Not really sure what code I can provide to be useful, but here's the code that causes Cypress to throw the uncaught exception
if (sample_condition) {
top.$('title').text(...).find('content') // Our iframe
} else {
top.$('title').text(page_title)
}
And there are more instances in our code where we access the top object, but they are generally similar. We found out the root cause of the issue is that within Cypress calls to "top" actually interface with Cypress instead of their intended environment which is our app.
This may not be a direct answer to your question, it's just expanding on your request for more information about the technique that I used to pass info from one script to another. I tried to do it within the same script without success - basically because the async nature of .then() stopped it from working.
This snippet is where I read a couple of id's from sessionStorage, and save them to a json file.
//
// At this point the cart is set up, and in sessionStorage
// So we save the details to a fixtures file, which is read
// by another test script (e2e-purchase.js)
//
cy.window().then(window => {
const contents = {
memberId: window.sessionStorage.getItem('memberId'),
cartId: window.sessionStorage.getItem('mycart')
}
cy.writeFile(`tests/cypress/fixtures/cart.json`, contents)
})
In another script, it loads the file as a fixture (fixtures/cart.json) to pull in a couple of id's
cy.fixture(`cart`).then(cart => {
cy.visit(`/${cart.memberId}/${cart.cartId}`)
})
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
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
I tried posting on their boards (authors of this library), however it literally takes months for them to reply when it comes to the free software (can't blame them).
But anyways
I have found that this library is behaving weirdly - for instance, a major problem with my application is when someone is trying to sign in (through FTP), they provide a correct login and mistype the password, no reply is received from FTP server.
I tried doing the same from command window just to verify that it's not the FTP server's fault; and FTP commands were received instantaneously.
It almost looks as though this library eats the commands. The same actions often times will yield different results.
Can anyone recommend a stable, reliable library to use with Compact framework? Or shed some light on this issue...?
I modified the source code inside ConnectThread() as follows:
// if a PWD is required, send it
if( response.ID == 331 )
{
response = SendCommand("PASS " + m_pwd, false);
//ADDED THIS - try again.
if (response.ID == 0)
{
response = SendCommand("PASS " + m_pwd, false);
}
//end of my addition
if( !((response.ID == 202) || (response.ID == 230)) )
{
m_cmdsocket.Close();
m_cmdsocket=null;
Disconnect();
m_connected = false;
return;
}
}
This solved the issue for awhile, until now it started doing it again, the culprit seems to be when 0 is coming back as a response from FTP server, the connection just stalls. I am not sure whether it is a socket issue or some other obscure problem, but I think I am going to give up at this point.
Which FTP set are you using, the stream-based classes in the SDF, or the separate one in the Forums? If you're using the one from the forums (which is the one I actually recommend), then you've got the source. I wrote that one from the ground up by looking at nothing by the RFC. It's really, really simple and if it's "eating" responses, it's likely a timeout issue, though it should be easy to put in a break point and see where it's coming apart.