Using Vue Resource with Vue.js v1
This is also running using vue-router and built with Browserfy.
I have vue-resource working on the whole for post and gets but I have one particular one which occasionally times out or so it seems. I confirm the server is getting the post request and then sending the response back but the webpage sits waiting as if it's missed the response. It seems to happen randomly. If i reload the page and resend then it works.
I've tried to replicate by pausing the server before the sending of the response, wait a bit then continue. In that case it works everytime and webpage continues as expected.
my post functions is as follows (slightly edited to shrink so easier to read)
this.saving = true;
// POST save to the database
this.$http.post('/api/savebr',
{
tNumber: parseInt(this.tNumber),
bNumber: parseInt(this.cNumber)
},
// I added the timeout for testing
{ timeout: 2000 }
).then((response) => {
this.completed.push(parseInt(this.cNumber));
this.saving = false;
}, (response) =>
{
// error callback
console.log(response);
this.saving = false;
alert('Could not save to server. Please try again.');
})
}
In above the timeout works if I pause the server. When the server continues the webpage ignores the response which I guess is correct.
When the webpage randomly misses the response the error callback is never done. It works if I alter response from server to be an error which is expected too.
The timeout option I added recently to see if that makes any odds and also tried with zero setting.
Is it possible to detect the timeout, cancel the current post and send a new one?
If I repeat the post, suddenly both seem to work and so the success code runs twice even though originally the first request seems to be stuck.
Sorry for long post and all pointers gratefully received.
Related
I am trying to receive Shopify webhooks in Google App Script and can do so, but Shopify requires a response in 5 seconds. If it doesn't get a response "200 OK" it will fire again and again until Shopify deletes your webhook. Not good for me...
I got my webhook deleted with the below code:
function doPost(e) {
//Do stuff (code note included)
return ContentService.createTextOutput('200 OK');
}
I suppose there could be 2 problems
The code is wrong.
The code takes longer than 5 seconds to execute or fails
I wish Shopify would give more info on webhook history so I could see if it's not getting a response. Any insights of how I can solve this problem.
Any ideas on how to solve this?
You state in your question that you do receive the webhook. The usual best practice is to verify the authenticity, and once that passes, you have the data (usually json). At that point, DO NOTHING but save the data for processing later, and return 200 OK as your response to the webhook.
DO NOT process the webhook, and then return 200 OK. The reason is quite simple. If your processing takes time, you kill your response back to Shopify in a timely manner.
A background job to process the data is ideal.
I have set up the eSignatures API for our app and until recently it has been working perfectly. The part that is now broken is the webhook function. So when a document gets signed by one of our clients, it triggers our webhook cloud function that then updates our database (seems simple?).
The problem is that eSignatures have now updated their timeout to only 8 seconds, which means that my function does not have enough time to run and respond to their servers. It does however still run and update the database correctly, but as it takes longer than 8 seconds, the 200 response never reaches eSignatures and therefore they retry the endpoint every hour (for ~5/6 hours). I have put in a catch so that data is not duplicated when this happens, but ideally we don't want the retries to take place!
My question is basically, is there a way to send a 200 response at the beginning of the function to eSginatures, and then continue with the updates? Or is there another solution to handle this timeout? As if anything does fail in the function, I still want to return a 4xx to eSignatures and in this case we will want the retry?
You can't send a response from your Cloud Functions and then continue executing tasks. When the response is sent, the Function is stopped. See this link and this one
But even if you could, sending a response before ending the tasks that your Cloud Function prevents you from sending a 4XX response if they fail. Hence, eSginatures would never retry.
I don't think you can do much else aside from possibly optimizing your Cloud Function or increasing the eSignatures timeout, which I don't think is possible ATM.
I am new to the Angular and Node javascript development.
My question is if i stop the Node server I want to show a warning message to the user and direct the user to the login screen, so can i call $modal.open to show a modal view page and on user confirmation redirect the user to login screen and close out the session. My apologies if this is a stupid question.
Thank you.
Once an Angular page has been loaded in the browser, the node server is irrelevant unless you start making Ajax calls -- the clientside angular code will happily keep on running clientside for as long as the user keeps the browser window open.
If your goal is to detect that the server has stopped responding to XHR requests (for whatever reason) and show a modal in response, you can certainly do that -- the following config block for example would globally catch any server error and let you Do Stuff as needed:
.config(function ($httpProvider) {
$httpProvider.interceptors.push(function ($q) {
return {
'responseError': function (err) {
// Do Stuff Here.
// (More realistically you'd want to inspect the contents of the
// 'err' variable to determine what type of error you're
// dealing with, and decide which Stuff to Do based on that)
return $q.reject(err); // pass the rejection on to any downstream promise handlers
}
};
});
});
(More detail here: https://docs.angularjs.org/api/ng/service/$http )
Whether you can use that to redirect to a login screen and let the user clear their session depends on how you're serving out that login screen, and how you're clearing out sessions -- if all of those are purely clientside operations in your setup, it'll work fine; if any depend on the server which you've stopped, then presumably it won't work fine.
Working on a single page application, and I am currently building a JQuery, ajax function for all of my calls to go through.
For a typical page I might have 3 ajax calls. My idea is if a users internet goes out to hold these ajax calls in an array. And then do a timer and keep checking if the user has internet. Once they have internet do the calls. So no calls are run when the user is offline (except for the check for internet one) and once their back online do what they wanted. So in my beforeSend I have this.
beforeSend : function($xhr)
{
self.ajaxPool.push($xhr);
if(!self.validateConnection())
{
console.log(self.ajaxPool);
}
}
So my question is when I get connection back, and loop through my array to each $xhr object what function can I call on it to say, 'Hey do what you were supposed to now'? For example $xhr.complete()? I've done a console log on the pool to look at the objects when connection is down but none of the functions it has look like they'd do the trick.
I would ditch the beforeSend entirely since you're using a pool anyways and do something like this...
//where you want to make your initial request somewhere in code
//do this INSTEAD of calling $.ajax(options)
ajaxPool.push(options);
//an interval to handle the queue
setInterval(function(){
//nothing in the pool so do nothing
if(ajaxPool.length < 1) return;
//not online so don't try to send
if(!validateConnection()) return;
//hey we're online lets make the ajax request
doAjax(ajaxPool.shift());
},200);
function doAjax(options){
//add call backs since you seem to be using a single call back
options.complete=function(data){ ... };
//do call
$.ajax(options);
}
You could make this more OOP and you could pause the interval when you know it's not being used, but I think this gets the basic concept across.
I been using this Offline JS for my RIA applications. It's really reliable for your offline scenarios
Monitors ajax requests looking for failure
Confirms the connection status by requesting an image or fake resource
Automatically grabs ajax requests made while the connection is down and remakes them after the connection is restored.
https://github.com/HubSpot/offline
I'm having a similar problem as: Find operation (AJAX request) rejected, not seen in the wire
However, in my case, I am making one request. This request works on normal page load. It fails to load silently after a form submit (not through ember), that redirects back to the same page. There is no AJAX request being made.
My main question is: how do I go about debugging issues like this?
What I've Tried
I've added console.log statements in all sorts of places to understand the request lifecycle.
Since I've read that promises can get rejected if something throws an exception within it, I've tried switching the chrome debugger to "Pause on all exceptions" (as opposed to "Pause on uncaught exceptions"). Of course it breaks at a bunch of exceptions like:
// This should fail with an exception
// Gecko does not error, returns false instead
try {
matches.call( div, "[test!='']:sizzle" );
But since I have a way to get the request to work and a way to get it to not work, I can easily compare the difference. I expected there to be an uncaught exception when my request failed, but no such luck.
I've also added a
Ember.RSVP.configure('onerror', function(error) {
console.log(error.message);
console.log(error.stack);
});
block, but it does not get called.
I've also poked around at different objects in the console to try and understand my application state:
store = App.__container__.lookup('store:main')
b = store.find('bundle')
b.isRejected // => true
b.reason.statusText // => "error"
Update: More Details
The project I am working on is backed by rails. I am using:
DEBUG: -------------------------------
DEBUG: Ember.VERSION : 1.0.0
DEBUG: Handlebars.VERSION : 1.0.0
DEBUG: jQuery.VERSION : 1.8.3
DEBUG: -------------------------------
And it doesn't show up in the debug output, but I'm using ember-data 1.0 beta 3:
// Version: v1.0.0-beta.3
// Last commit: 2259c27 (2013-09-28 19:24:07 -0700)
The app loads all of the bundles to render them and a form, but the form submits directly to rails. Rails processes the post request and redirects back to /, where the ember app lives.
The first request to / loads everything fine, but when I submit the form, and it redirects back, that's when my ajax call my call to store.find('bundle') does nothing.
UPDATE
I've discovered that my issue is related to pusher (websockets).
The issue seems intermittent and I've only seen it in Chrome (I've only tested Firefox).
The issue went away when I disconnected from websockets before a page refresh.
In your case the fail handler is receiving the jQuery XMLHttpRequest. Try to see what responseText and status is returning.
App.__container__.lookup('store:main').find('bundle').then(null, function(reason) {
reason.responseText // response from the server, maybe can show an error page in html
reason.status // 404 page not found, 500 some server error you will need to chech the logs etc.
});
I hope it helps