Shopify - Webhook for getting notified on Rates API call timeout
up vote
0
down vote
favorite
In Shopify, normally the Rates API call will succeed only if we return the rates within the 15 seconds. Else, it will display an error at the Checkout page.
I looked a glance at the webhook list in the settings page and seems like there is not such webhook for Rate API timeout error.
Is there any way to get notified of these scenarios?
shopify webhooks shopify-app
asked Nov 22 at 14:13
lalith kumar
335
add a comment |
up vote
0
down vote
favorite
In Shopify, normally the Rates API call will succeed only if we return the rates within the 15 seconds. Else, it will display an error at the Checkout page.
I looked a glance at the webhook list in the settings page and seems like there is not such webhook for Rate API timeout error.
Is there any way to get notified of these scenarios?
shopify webhooks shopify-app
asked Nov 22 at 14:13
lalith kumar
335
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
In Shopify, normally the Rates API call will succeed only if we return the rates within the 15 seconds. Else, it will display an error at the Checkout page.
I looked a glance at the webhook list in the settings page and seems like there is not such webhook for Rate API timeout error.
Is there any way to get notified of these scenarios?
shopify webhooks shopify-app
asked Nov 22 at 14:13
lalith kumar
335
In Shopify, normally the Rates API call will succeed only if we return the rates within the 15 seconds. Else, it will display an error at the Checkout page.
I looked a glance at the webhook list in the settings page and seems like there is not such webhook for Rate API timeout error.
Is there any way to get notified of these scenarios?
shopify webhooks shopify-app
shopify webhooks shopify-app
asked Nov 22 at 14:13
lalith kumar
335
asked Nov 22 at 14:13
lalith kumar
335
asked Nov 22 at 14:13
lalith kumar
335
asked Nov 22 at 14:13
lalith kumar
335
asked Nov 22 at 14:13
lalith kumar
335
335
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
If your App is failing to return a response in 15 seconds, you can easily see that yourself by monitoring the response times of your App. Most cloud providers will log your response times for you to see. If not there are plenty of monitoring tools designed to expose your App response times in an easy way. Try that.
answered Nov 22 at 16:13
David Lazar
5,38831426
Also your rate service should throw a connection closed error if you take too long to respond so you could catch that and forward that to a monitoring service
– bknights
Nov 22 at 22:21
Hi @david and bknights, Thanks for your response. However, the elapsed time calculation is not effective in our system, and i resolved my scenario by listening to the req.on('close' , ...) event (please have a look at my answer posted below). The reason for assuming the elapsed time calculation as not effective, because, on req.on('close'), i observed the elapsed time as 10 to 11 seconds only. So, now this req.on('close') resolved this, and eventhe Gateway timeout issue as well.
– lalith kumar
Nov 27 at 10:34
add a comment |
up vote
0
down vote
Got solution for this scenario as below. We can usually listen for connection close event.
app.post('/fetchrates', (req, res) => {
req.on('close', () => {
logger.debug("Shopify has aborted/closed the connection");
});
// <Logic for calculating the rates and returning the response>
});
This seems to be the best solution, since not only with the timeout, we can also get notified on gateway timeout(where the api endpoint has not been hitted into our system).
answered Nov 27 at 10:30
lalith kumar
335
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
If your App is failing to return a response in 15 seconds, you can easily see that yourself by monitoring the response times of your App. Most cloud providers will log your response times for you to see. If not there are plenty of monitoring tools designed to expose your App response times in an easy way. Try that.
answered Nov 22 at 16:13
David Lazar
5,38831426
Also your rate service should throw a connection closed error if you take too long to respond so you could catch that and forward that to a monitoring service
– bknights
Nov 22 at 22:21
Hi @david and bknights, Thanks for your response. However, the elapsed time calculation is not effective in our system, and i resolved my scenario by listening to the req.on('close' , ...) event (please have a look at my answer posted below). The reason for assuming the elapsed time calculation as not effective, because, on req.on('close'), i observed the elapsed time as 10 to 11 seconds only. So, now this req.on('close') resolved this, and eventhe Gateway timeout issue as well.
– lalith kumar
Nov 27 at 10:34
add a comment |
up vote
0
down vote
If your App is failing to return a response in 15 seconds, you can easily see that yourself by monitoring the response times of your App. Most cloud providers will log your response times for you to see. If not there are plenty of monitoring tools designed to expose your App response times in an easy way. Try that.
answered Nov 22 at 16:13
David Lazar
5,38831426
Also your rate service should throw a connection closed error if you take too long to respond so you could catch that and forward that to a monitoring service
– bknights
Nov 22 at 22:21
Hi @david and bknights, Thanks for your response. However, the elapsed time calculation is not effective in our system, and i resolved my scenario by listening to the req.on('close' , ...) event (please have a look at my answer posted below). The reason for assuming the elapsed time calculation as not effective, because, on req.on('close'), i observed the elapsed time as 10 to 11 seconds only. So, now this req.on('close') resolved this, and eventhe Gateway timeout issue as well.
– lalith kumar
Nov 27 at 10:34
add a comment |
up vote
0
down vote
up vote
0
down vote
If your App is failing to return a response in 15 seconds, you can easily see that yourself by monitoring the response times of your App. Most cloud providers will log your response times for you to see. If not there are plenty of monitoring tools designed to expose your App response times in an easy way. Try that.
answered Nov 22 at 16:13
David Lazar
5,38831426
If your App is failing to return a response in 15 seconds, you can easily see that yourself by monitoring the response times of your App. Most cloud providers will log your response times for you to see. If not there are plenty of monitoring tools designed to expose your App response times in an easy way. Try that.
answered Nov 22 at 16:13
David Lazar
5,38831426
answered Nov 22 at 16:13
David Lazar
5,38831426
answered Nov 22 at 16:13
David Lazar
5,38831426
answered Nov 22 at 16:13
David Lazar
5,38831426
5,38831426
Also your rate service should throw a connection closed error if you take too long to respond so you could catch that and forward that to a monitoring service
– bknights
Nov 22 at 22:21
Hi @david and bknights, Thanks for your response. However, the elapsed time calculation is not effective in our system, and i resolved my scenario by listening to the req.on('close' , ...) event (please have a look at my answer posted below). The reason for assuming the elapsed time calculation as not effective, because, on req.on('close'), i observed the elapsed time as 10 to 11 seconds only. So, now this req.on('close') resolved this, and eventhe Gateway timeout issue as well.
– lalith kumar
Nov 27 at 10:34
add a comment |
Also your rate service should throw a connection closed error if you take too long to respond so you could catch that and forward that to a monitoring service
– bknights
Nov 22 at 22:21
Hi @david and bknights, Thanks for your response. However, the elapsed time calculation is not effective in our system, and i resolved my scenario by listening to the req.on('close' , ...) event (please have a look at my answer posted below). The reason for assuming the elapsed time calculation as not effective, because, on req.on('close'), i observed the elapsed time as 10 to 11 seconds only. So, now this req.on('close') resolved this, and eventhe Gateway timeout issue as well.
– lalith kumar
Nov 27 at 10:34
Also your rate service should throw a connection closed error if you take too long to respond so you could catch that and forward that to a monitoring service
– bknights
Nov 22 at 22:21
Also your rate service should throw a connection closed error if you take too long to respond so you could catch that and forward that to a monitoring service
– bknights
Nov 22 at 22:21
Hi @david and bknights, Thanks for your response. However, the elapsed time calculation is not effective in our system, and i resolved my scenario by listening to the req.on('close' , ...) event (please have a look at my answer posted below). The reason for assuming the elapsed time calculation as not effective, because, on req.on('close'), i observed the elapsed time as 10 to 11 seconds only. So, now this req.on('close') resolved this, and eventhe Gateway timeout issue as well.
– lalith kumar
Nov 27 at 10:34
Hi @david and bknights, Thanks for your response. However, the elapsed time calculation is not effective in our system, and i resolved my scenario by listening to the req.on('close' , ...) event (please have a look at my answer posted below). The reason for assuming the elapsed time calculation as not effective, because, on req.on('close'), i observed the elapsed time as 10 to 11 seconds only. So, now this req.on('close') resolved this, and eventhe Gateway timeout issue as well.
– lalith kumar
Nov 27 at 10:34
add a comment |
up vote
0
down vote
Got solution for this scenario as below. We can usually listen for connection close event.
app.post('/fetchrates', (req, res) => {
req.on('close', () => {
logger.debug("Shopify has aborted/closed the connection");
});
// <Logic for calculating the rates and returning the response>
});
This seems to be the best solution, since not only with the timeout, we can also get notified on gateway timeout(where the api endpoint has not been hitted into our system).
answered Nov 27 at 10:30
lalith kumar
335
add a comment |
up vote
0
down vote
Got solution for this scenario as below. We can usually listen for connection close event.
app.post('/fetchrates', (req, res) => {
req.on('close', () => {
logger.debug("Shopify has aborted/closed the connection");
});
// <Logic for calculating the rates and returning the response>
});
This seems to be the best solution, since not only with the timeout, we can also get notified on gateway timeout(where the api endpoint has not been hitted into our system).
answered Nov 27 at 10:30
lalith kumar
335
add a comment |
up vote
0
down vote
up vote
0
down vote
Got solution for this scenario as below. We can usually listen for connection close event.
app.post('/fetchrates', (req, res) => {
req.on('close', () => {
logger.debug("Shopify has aborted/closed the connection");
});
// <Logic for calculating the rates and returning the response>
});
This seems to be the best solution, since not only with the timeout, we can also get notified on gateway timeout(where the api endpoint has not been hitted into our system).
answered Nov 27 at 10:30
lalith kumar
335
Got solution for this scenario as below. We can usually listen for connection close event.
app.post('/fetchrates', (req, res) => {
req.on('close', () => {
logger.debug("Shopify has aborted/closed the connection");
});
// <Logic for calculating the rates and returning the response>
});
This seems to be the best solution, since not only with the timeout, we can also get notified on gateway timeout(where the api endpoint has not been hitted into our system).
answered Nov 27 at 10:30
lalith kumar
335
answered Nov 27 at 10:30
lalith kumar
335
answered Nov 27 at 10:30
lalith kumar
335
answered Nov 27 at 10:30
lalith kumar
335
335
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53432868%2fshopify-webhook-for-getting-notified-on-rates-api-call-timeout%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
