Skip to content
This repository has been archived by the owner on Dec 19, 2019. It is now read-only.

Fixed internal server error for query urlResolver #445

Conversation

yogeshsuhagiya
Copy link
Member

@yogeshsuhagiya yogeshsuhagiya commented Mar 6, 2019

Description (*)

  • If Custom URL Rewrite is not autogenerated means manually created from backend then try to find relative_url based on target path.
  • Case 1: If target path is correct then return the result.
  • Case 2: If target path is wrong, means there no category, product, and cms page exists then throws erros.

Fixed Issues (if relevant)

  1. Internal server error for query urlResolver while message "We can't find products matching the selection." appears on frontend #436

Manual testing scenarios (*)

1. Create Custom URL Rewrite

  • Request Path: bla-bla-bla
  • Target Path: catalog/category/view/id/5
  • Redirect Type: No

2. Perform query:

query{
  urlResolver(
    url: "bla-bla-bla"
  ) {
    id
    relative_url
    type
  }
}

3. Result:

{
    "data": {
        "urlResolver": {
            "id": 5,
            "canonical_url": "catalog/category/view/id/5",
            "type": "CATEGORY"
        }
    }
}

Contribution checklist (*)

  • Pull request has a meaningful description of its purpose
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All commits are accompanied by meaningful commit messages
  • All automated tests passed successfully (all builds on Travis CI are green)

@naydav
Copy link
Contributor

naydav commented Mar 6, 2019

@yogeshsuhagiya
Also, need to check failed test
https://travis-ci.com/magento/graphql-ce/jobs/182696242

…sh-1

Changed canonical_url to relative_url
@yogeshsuhagiya
Copy link
Member Author

Hi @naydav , can you help with the following issue?

log: 
✓ SIGNIFYD_GLOBAL object initialization check
 jsbuild module
   - caches original load method...X caches original load method
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (1)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (2)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (3)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (4)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (5)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (6)
   - loads external files...
Warning: PhantomJS timed out, possibly due to an unfinished async spec. Use --force to continue.
Aborted due to warnings.

@yogeshsuhagiya
Copy link
Member Author

Hi @naydav, can you please review this PR?

1 similar comment
@yogeshsuhagiya
Copy link
Member Author

Hi @naydav, can you please review this PR?

@naydav
Copy link
Contributor

naydav commented Apr 3, 2019

@galaoleksandr
Please, verify this PR from QA side
Thanks

@naydav
Copy link
Contributor

naydav commented Apr 3, 2019

Hi @naydav , can you help with the following issue?

log: 
✓ SIGNIFYD_GLOBAL object initialization check
 jsbuild module
   - caches original load method...X caches original load method
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (1)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (2)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (3)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (4)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (5)
     Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. (6)
   - loads external files...
Warning: PhantomJS timed out, possibly due to an unfinished async spec. Use --force to continue.
Aborted due to warnings.

Hi @yogeshsuhagiya
It was just random fail on Travis

Sorry for a delay, it is because that current milestone is devoted to Checkout workflow and Performance Improvement. But all of the PRs will be processed.

@galaoleksandr
Copy link

galaoleksandr commented Apr 4, 2019

@yogeshsuhagiya Hello. Tried to use wrong request path, but no error message appeared.
image

@yogeshsuhagiya
Copy link
Member Author

Hi @galaoleksandr, currently I'm writing the Test Case. I'm sure you'll definitely face this message.

@@ -73,6 +74,11 @@ public function resolve(
$url = $customUrl ?: $url;
$urlRewrite = $this->findCanonicalUrl($url);
if ($urlRewrite) {
if (!$urlRewrite->getEntityId()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We hide errors here.

Simple example:

  1. Create Custom URL Rewrite
    Request Path: go-to-admin
    Target Path: /admin
    Redirect Type: No
  2. Perform query:
query{
  urlResolver(
    url: "go-to-admin"
  ) {
    id
    relative_url
    type
  }
}

For this case expected response in Internal Server Error which means

Exception #0 (LogicException): Front controller reached 100 router match iterations

but we simply got "No such entity found with matching URL key: go-to-admin"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be better to rely on Magento error handling then just check if our response is casting to true or false? @naydav?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exception #0 (LogicException): Front controller reached 100 router match iterations
Looks like it's bug in Magento. expected result: 404 Page not found

Does everything else work?

@TomashKhamlai
Copy link
Contributor

TomashKhamlai commented Apr 23, 2019

Generally it works for redirect type 'No'. But hides the error if problem occurred during request.

magento2#21580

@TomashKhamlai TomashKhamlai added QA failed and removed QA in progress We are checking labels Apr 23, 2019
@TomashKhamlai
Copy link
Contributor

TomashKhamlai commented Apr 25, 2019

@yogeshaureatelabs, could you please update your fork.

You can do it easily by following these steps:

# check connected remotes
git remote -v

# add upstream remote if not configured. ("mainline" is just a name. The default remote is always called "origin")
git remote add mainline https://github.com/magento/graphql-ce.git

# download from the remote
git fetch mainline

# check the current active branch
git branch

# checkout to 2.3-develop of your fork
git checkout 2.3-develop

# merge changes from the upstream to your fork
git merge mainline/2.3-develop

# optionally push everything or just commit and go to next step
git push origin 2.3-develop

# checkout to the branch of your PR
git checkout 2.3-develop-graphql-PR-yogesh-2

# merge 2.3-develop to your branch
git merge 2.3-develop

# Update pull request. It will trigger travis tests automatically.
git push origin 2.3-develop-graphql-PR-yogesh-2

@yogeshsuhagiya
Copy link
Member Author

@TomashKhamlai Sure

@yogeshsuhagiya
Copy link
Member Author

Hi @TomashKhamlai
I've followed the sequence of git command which you had given and updated the 2.3-develop-graphql-PR-yogesh-2 branch.

@yogeshsuhagiya
Copy link
Member Author

Hi @TomashKhamlai, @naydav will anyone please let me know how much more time needs to process this PR because approx 50 days have been already passed but still waiting.

@TomashKhamlai
Copy link
Contributor

@yogeshsuhagiya, sorry for the delays. I will try to explain what is happening now and how it has influence on PR processing.

Magento follows practices for backward compatible development. This requires from developers to concentrate all the effort on little component and avoid mistakes that will be hard or even impossible to fix after release. So there is a difference between magento2(deliver fixes as soon as possible, improve the existing functionality) and graphql-ce(create functionality, do less but do best and cover everything with tests like a mad :) ) PR processing.

I haven't seen any roadmap documented (doesn't mean that it doesn't exist) but now the main focus is around the checkout process and bug fixing. As far as I know next prioritized PRs will be related to My Account activity. For keeping track on the Community activity the best option is to join the weekly #graphql synс-up that is held on Tuesdays and participate in Slack channel. You can get more information on our Magento Community Engineering Slack #graphql

We appreciate your work and your patience. You are not alone:
#392 (comment)
#500 (comment)

@TomashKhamlai
Copy link
Contributor

@naydav, I mentioned about error-masking. If it is allowed, I would accept this PR. From my point of view it would be better even to mask this issue magento/magento2#21580 too.
#625 is still open.

Functionally works. Negative testing was performed

@magento-engcom-team magento-engcom-team merged commit ec2ee49 into magento:2.3-develop May 10, 2019
@ghost
Copy link

ghost commented May 10, 2019

Hi @yogeshsuhagiya, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.

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

Successfully merging this pull request may close these issues.

None yet

5 participants