redirect issue and PR URLs to the correct ticket type #4626

Open

naikaayush.com 1w ago

Open opened by

naikaayush.com 1w ago

issues and PRs now share a numbering sequence, but opening a valid ticket under the wrong URL currently shows “not found.”

eg: if #4000 is a PR, visiting: /<owner>/<repo>/issues/4000 should redirect to its PR page

steps to reproduce:

find a PR, for example #4000.
replace /pulls/4000/... with /issues/4000.
the web app reports that the issue was not found, even though ticket #4000 exists.

expected behavior:

/issues/4000 redirects to the PR page when #4000 is a PR.
/pulls/4000 redirects to the issue page when #4000 is an issue.
a genuinely missing ticket still returns 404.
tickets opened through the correct URL behave as before.

oppi.li 3d ago

what is the motivation for this? is this so that anybody can link to /issues/<id> and correctly be redirected as necessary? if that is the case, perhaps it might be nice to have /tickets/<id> that routes to the best location?

naikaayush.com 3d ago

i was just trying to have github-like behavior, because usually someone says "oh are you tracking #3300", and not sure if it's a pr or an issue. idk if this is just me, or happens commonly

oppi.li 3d ago

yeah thats fair! i'm wonder if it helps to have a neater URL here like /tickets/N for ambiguous identifiers instead of, say, typing /issues/N and having the frontend error correct!

naikaayush.com 3d ago

had put up a pr for this: #4674

i’d lean towards keeping it in the web layer. issue vs pr is only a distinction in our urls (it’s one ticket record underneath), so the web app is the only place that knows to fix the mismatch

both pages already fetch the ticket, and the pr loader had a TODO: redirect to issue page right there, so this mostly fills that in

not sure /tickets/N fits as well though: people would have to know it exists, whereas /issues and /pulls are what they’d naturally type or paste anyway.

open to other ideas if you see a better place for it!