Redirection not working

I am able to reproduce similar kind of scenario.
Like i have created two nodes with URL alias as "/redirect-1" and "/redirect-2". Now i have added redirect rule in which i have source as "/redirect-2" and destination as "/redirect-1".
Now if i hit "/redirect-2" then it doesn't get redirected to "/redirect-1".
It looks like we need to add node id ('node/nid') in redirection rule (for source node which are having some url alias).
If it is the same scenario you are facing then requesting you to try with adding node id "node/nid" in redirect rule. Though i tried below work around on my local and it works for me.

Added below line of code in file : /src/EventSubscriber/RedirectRequestSubscriber.php

@@ -136,6 +136,7 @@ class RedirectRequestSubscriber implements EventSubscriberInterface {
// Do the inbound processing so that for example language prefixes are
// removed.
$path = $this->pathProcessor->processInbound($request->getPathInfo(), $request);
+ $path = \Drupal::service('path_alias.manager')->getAliasByPath($path);
}
$path = trim($path, '/');

Seeing the same issue, the code added in #2 inside RedirectRequestSubscriber.php also working locally for me.
Adding a node id may not be good for a client so I think amending the code instead is the way forward.. with a patch?

I've tested the patch in #4 with Drupal 10.1.6 and Redirect 8.x-1.9.It resolves the issue for me.

I tested this patch locally and it causes a redirect loop on the homepage and crashes it. It did fix the redirect but not usable due to the loop.

verified the provided patch, and it is functioning as expected in my local environment. Raising MR !80 to fix the issues related to test cases effectively.

I've since seen this patch causing a redirect loop, where a redirect alias is pointing to itself.
It works in all other cases but maybe because of the redirect loop, this is not ready for a MR?

Also, I just took the code already mention in comment #2 and placed it in a patch..
it may not be the best approach?

I've been experiencing similar issues and have tried the patch. So far, so good. But will need more testing. I'm not sure how Redirect currently handles redirects pointing to itself but a redirect loop sounds like it would be the expected behaviour to me. Before applying the patch, what happened in that example? Did it resolve itself or something else?

I'm going to put this into RTBC because I'm not experiencing any redirect loops and we've fairly thoroughly tested the patch in a staging environment with no experience of redirect loops. And in fact, trying to create a redirect to itself the module flags this and gives a error message.

Trying again to change status - it didn't change before!

@welly could you confirm if you've tested the patch in #4 or the MR please?

@Steven Jones, that was the patch in #4 I tested and have been using. Cheers!

Have been experiencing redirect loops on a site we're using the patch with so back to "needs work" and I'll try and have a look at this myself.

#4 is causing `Service unavailable` errors all over my site. Also doesn't comply with coding standards and `$path` is assigned a value twice.

Hi, I experience this issues also, any progress please? Greetings,

Hi,

i'am facing the same problem and after some debug i figured that the findMatchingRedirect($source_path, array $query = [], $language = Language::LANGCODE_NOT_SPECIFIED) method doesn't able to get the right hash from database in some cases.

The source_path passing to the method is a /node/nid but in database the redirect_source__path is an alias without langcode.

The language used to generate array of hashes to query database is the current of the redirect_source__path or und but never the other so an "en" source to a "fr" destination can't work.

And The Url object use to the redirection once the right redirection is found is from the original request and not from redirection.

Maybe i'am wrong but for me the language of the redirection is the language of the destination but it seem to be these of the origin.

No time to investigate more but there is a dirty quick test patch which seem to fix it in my tests cases

Seeing the same issue #20 has fixed the issue