What did you do? ================ 1. Log into MDN Web Docs as user with page creation permissions 2. Go to https://developer.mozilla.org/en-US/docs/API/Window What happened? ============== An Internal Server Error What should have happened? ========================== New page creation should start, with https://developer.mozilla.org/en-US/docs/Web/API as parent document. Is there anything else we should know? ====================================== Part of the bug fix for bug 1052510 included resolving parent redirects as part of new page creation. This code assumes that only relative references are used in valid redirects, such as: /en-US/docs/API/Window The redirect for this document (possibly created manually) is a full URL: https://developer.mozilla.org/en-US/docs/API/Window The code checks for full URLs and refuses to parse them, returning False: https://github.com/mozilla/kuma/blob/1bed365b259351e93faab4e914b2ed77f6fa2dae/kuma/wiki/utils.py#L60-L67 The new document code does not handle the case where the following the redirect sets the parent to None, resulting in the exception: https://github.com/mozilla/kuma/blob/1bed365b259351e93faab4e914b2ed77f6fa2dae/kuma/wiki/views/document.py#L574-L578 Tracked in sentry: Public: https://sentry.prod.mozaws.net/share/issue/37332e34333531393130/ Staff: https://sentry.prod.mozaws.net/operations/mdn-prod/issues/4351910/

Fixed for this case by manually updating https://developer.mozilla.org/en-US/docs/API/Window. Looking to see how many additional pages have this issue.

254 redirect documents include full URLs. Some possible fixes: 1) Adjust the parent document redirect following to allow full URLs on developer.mozilla.org. 2) Update Document.get_redirect_url() to return the relative reference. 3) Update the 254 documents manually to use relative URLs. 4) Eliminate the issues by re-implementing redirects (bug 1364709).

I strongly believe the 2 number point is most acceptable solution because the document should have relative url instead of full url. But it may need some time to write a script or do it manually. In the meantime, I am going to submit a patch which will eliminate it.

Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/616dda0a1bed25fd5107826ef918957242347dc8 bug 1465085: Tests for get_doc_components_from_url Refactor the tests for get_doc_components_from_url to pytest style, and expand the test cases. https://github.com/mozilla/kuma/commit/1c49677006f52a2a7c6f1d6773d8ac9d50fcfda2 bug 1465085: Refactor some Document model tests Refactor DocumentTests to pytest style, and expand some tests cases. https://github.com/mozilla/kuma/commit/f7596e4cd3572b49a79d8950a78d83407e275a0e bug 1465085: Parse full URL for local domains In get_doc_components_from_url with check_host=True, continue parsing full URLs on the local domain. https://github.com/mozilla/kuma/commit/29cda03dbbe83a14efe336411739798e33f25dc0 bug 1465085: Return the path from a full URL Redirect URLs are allowed to be the full URL to a local document. Process these and return just the path. https://github.com/mozilla/kuma/commit/f264fe85288cb6fb019423a2c27c44977309ec51 Merge pull request #4863 from safwanrahman/redirect_fix bug 1465085: Handle a child of a redirect with a full URL without raising an error

Deployed to production, https://developer.mozilla.org/en-US/docs/API/Window now starts the Create a New Article workflow.

I was a little quick to close this one. I'd fixed /API/Window by fixing the redirect, so it wasn't a good test. This document has a standard redirect: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_GetPropertyByIdDefault to https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_GetPropertyDefault and creating a new subpage works: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_GetPropertyByIdDefault/SubPage There are several non-standard redirects. For example, this URL: https://developer.mozilla.org/en-US/Extensions is a redirect to: https://developer.mozilla.org/en-US/Add-ons and raises a 500 error when you view: https://developer.mozilla.org/en-US/Extensions/SubPage This is also a redirect to a zoned URL, which is scheduled for removal in bug 1462475. I'm going to see how many "non-standard" redirects there are that remain problems, to see if it is useful to write more code or manually fix them.

There are 74 bad redirects remaining, or 30% of the original 254. This seems like it could be fixed quickly.

I manually fixed 66 of the redirects. There are 8 remaining that are redirects to non-documents. For example, https://developer.mozilla.org/en-US/docs/Main_page redirects to the homepage. Going to a subpage of one of these redirects (https://developer.mozilla.org/en-US/docs/Main_page/SubPage) still results in a 500 ISE when logged in. Instead, we should return a 404.

Opened https://github.com/mozilla/kuma/pull/4887 to fix issue. Tracked in sentry: https://sentry.prod.mozaws.net/share/issue/37332e34333838303638/

Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/73edca756852b4e176981d1c569dfa5e1cabb4cc bug 1465085: Return 404 for child of non-doc 301 If /en-US/docs/Main_page is a redirect to a non-Document MDN URL, then return a 404 to /en-US/docs/Main_page/SubPage when logged in, rather than raise an Internal Server Error (500 ISE). https://github.com/mozilla/kuma/commit/4b5577b4cb52518b9f290337f741fbb6e5936178 Merge pull request #4887 from jwhitlock/subpage-404-1465085 bug 1465085: Return 404 for the child of a 301 to a non-document URL

Fix deployed to production, https://developer.mozilla.org/en-US/docs/Main_page/SubPage is now 404.