Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing PDP of a non-existent, inactive or archived product responds with 500 instead of 404. #2261

Open
alexanderfc opened this issue Jun 20, 2017 · 10 comments

Comments

@alexanderfc
Copy link
Contributor

Env: stage

Steps:

  1. Try to access details page of non-existent product, e.g.:
    https://stage.foxcommerce.com/perfect-gourmet/products/product-6969803
  2. Look at the error in response.

Actual result: 500
Expected result: 404

Screenshot:

2017-06-21 01 15 15

@alexanderfc alexanderfc changed the title Accessing PDP of non-existing, inactive or archived product responds with 500 instead of 400. Accessing PDP of a non-existent, inactive or archived product responds with 500 instead of 400. Jun 20, 2017
@alexanderfc alexanderfc changed the title Accessing PDP of a non-existent, inactive or archived product responds with 500 instead of 400. Accessing PDP of a non-existent, inactive or archived product responds with 500 instead of 404. Jun 20, 2017
@michalrus michalrus self-assigned this Jun 21, 2017
@michalrus
Copy link
Contributor

michalrus commented Jun 21, 2017

@alexanderfc, if you ask the Phoenix there directly, it does respond with 404 (log below). So, I’d initially guess the issue is in Ashes’ Storefront’s JS backend?

@bagratinho, do you want to check that? Or whom should we ask?

% curl -v https://stage.foxcommerce.com/api/v1/public/products/product-6969803

*   Trying 10.240.0.35...
* TCP_NODELAY set
* Connected to stage.foxcommerce.com (10.240.0.35) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.foxcommerce.com
*  start date: Sep 18 00:00:00 2016 GMT
*  expire date: Sep 18 23:59:59 2017 GMT
*  subjectAltName: host "stage.foxcommerce.com" matched cert's "*.foxcommerce.com"
*  issuer: C=US; O=GeoTrust Inc.; CN=RapidSSL SHA256 CA
*  SSL certificate verify ok.
> GET /api/v1/public/products/product-6969803 HTTP/1.1
> Host: stage.foxcommerce.com
> User-Agent: curl/7.53.1
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Server: nginx
< Date: Wed, 21 Jun 2017 08:11:09 GMT
< Content-Type: application/json
< Content-Length: 57
< Connection: keep-alive
< 
* Connection #0 to host stage.foxcommerce.com left intact
{"errors":["product with key=product-6969803 not found"]}

@michalrus michalrus removed their assignment Jun 21, 2017
@michalrus
Copy link
Contributor

michalrus commented Jun 21, 2017

It would be beneficial if someone looked at that while we still have a repro. :P After Stage is redeployed, and reseeded, and Alexander runs QA tests, it might no longer be so.

@bagratinho
Copy link
Contributor

@michalrus, @alexanderfc I'll check this

@michalrus
Copy link
Contributor

Awesome. :)

@bagratinho
Copy link
Contributor

image
Guys , this is what I see when reproducing with postman.
As you can see it returns 500, but writes not found in error message.
Shouldnt server be returning 404?

@anru
Copy link
Contributor

anru commented Jun 21, 2017

it's storefront's server response

@bagratinho
Copy link
Contributor

I see that in server/app.js error are handled with koa-onerror lib.

class App extends KoaApp {

  constructor(...args) {
    super(...args);
    onerror(this);

have no idea what could be done here, to fix this behavior, no experience with node server

@anru
Copy link
Contributor

anru commented Jun 21, 2017

@bagratinho I could take this task after I'll finish my current one

@kairome
Copy link
Contributor

kairome commented Jun 21, 2017

Same issue exists for PURE, will drop a fix tomorrow

@kairome
Copy link
Contributor

kairome commented Jun 22, 2017

If anybody's curious as to why it was 500, here's the PR
FoxComm/api-js#47

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants