Url Tracker 11 doesn't force redirect on Azure App Service

[HarrySpyrou]

Describe the bug Url Tracker 11.0.1 - Umbraco 11.4.2

A clear and concise description of what the bug is:

Force redirects doesn't seem to work on a load balanced setup in Azure. I'm using setup and terminology from official docs

When there is a backoffice server and at least one Front-end server (server = Azure App Service) using Url Tracker, only specific redirects seem to work. Specifically:

Works: origin page does not exist -> target page exists Doesn't work: Origin page exists -> Force redirect to target page that also exists

In that case, it seems to be doing nothing. I can see happening on two different projects. The front-end server(s) will not have the redirect in place. I'm not 100% sure it's a bug, but all the testing I could do, it seems like it's one.

To Reproduce Steps to reproduce the behavior:

1. Spin up any Umbraco 10/11 project
2. Set a page to redirect from
3. Set a page to redirect to as a target (302/301 doesn't matter)
4. Enable force redirect and save.

Expected behavior Even if both pages exist, if I force redirect from page A to page B, it should comply.

Desktop (please complete the following information):

• Linux Ubuntu Azure App Service (I think its OS is irrelevant pretty sure it happens on Windows too).

Additional context As I said I'm not 100% sure that this is a bug, as there's one instance in Azure that I have that seems to work but without any differences in configurations etc as far as I can see. Feel free to instruct me if I'm doing something wrong and I'm available to help test it or if anything else is needed.

[D-Inventor]

Hi! Thanks for the detailed report!

I'm pretty sure I know what's going on. It's been on my todo list for a while, but I haven't taken the time to actually implement it yet. You're likely suffering from stale memory caches.

For performance, the URL Tracker keeps previously made matches in a memory cache. However, if you update your redirects, the URL Tracker only updates the memory cache on the Publisher server. You can verify if this is the case by simply rebooting your subscriber servers and checking if the redirect starts working then.

I don't have a quick fix available, but if you're comfortable with loadbalancing, you might be able to build a workaround:

• A custom CacheRefresherNotification should notify all subscriber servers that the redirects have changed
• You can fire the notification using the DistributedCache service, which can be injected with dependency injection.
• To check for changes in the redirects, you can create a decorator, much like the cache sub-package of the URL Tracker.
• Then you can register a notification handler for your custom notification and clear the redirect cache whenever that notification is fired. Simply inject the IInterceptCache type in your notification handler and call the .Clear() method on there, just like what the cache sub-package does.

This should clear the redirect cache on all subscriber servers when a change is made on the publisher server.

Does that suffice or would you prefer to wait until I can build a fix?

[HarrySpyrou]

Hey thanks for the reply, I appreciate it. I understand what you mean and it was in my mind too. Is it something you're planning on fixing overall or shouldn't I wait?

I'll try restarting the application as a first step to see if this is fixed and then consult the rest of the team. I'll report back if a restart fixed it.

[HarrySpyrou]

Sorry for the double post, but a question I have here is:

Why does the caching work when there is no source page? Doesn't that suffer from the same problem?

[D-Inventor]

Good questions, top to bottom:

Is it something you're planning on fixing overall or shouldn't I wait?

I've been meaning to fix this, but since nobody really noticed the issue, I put it on very low priority. Especially because I do this in my spare time and I am attempting to focus on a big redesign. Now since you're actively experiencing inconvenience with this issue, I could give it more priority. So... should you wait? Depends how pressing this issue is for you. It's my spare time, so I can't commit to a deadline. If you need this solution before the end of this week, I'd say don't wait. If you can live with the issue, then perhaps you can wait. I do aim to fix all the issues here, but it may take a bit more than a week. If you decide not to wait, it may be worth consideration to make a fork of this repository and send me a pull request of the fix that your team has made. The URL Tracker is open for contributions. If you're interested to contribute to the URL Tracker, please let me know so I can give some additional instructions.

Why does the caching work when there is no source page? Doesn't that suffer from the same problem?

I'm speculating here, but I think it actually does suffer from the same problem, but the circumstances are likely different. All responses from the URL Tracker are cached per URL. If a URL is visited and no redirect was found, this is cached so we don't search again. The important bit here is that this happens when the URL is visited. Since URLs for non-existing pages are usually not visited very often, it's likely that the cache entries for non-existing pages don't exist or have expired. By default, responses are cached for 2 days after the last visit.

[HarrySpyrou]

Thanks for the details, I understand what you mean. We'll look to do something probably on our side. Thanks again!

[Yannis-S-Standaert]

I ran into the same issue, so a fix would be nice to make it usable for larger sites. Thanks for the workaround, we'll try that for now!

[D-Inventor]

I released a beta version for Umbraco 10 and Umbraco 13 with a fix for this issue. Versions 10.4.0-beta0001 and 13.1.0-beta0002 respectively. I would love it if you could give it a try!

In addition to a fix for this issue, these beta releases contain a new "active" cache that aims to improve performance. It is turned off by default, but can be turned on using a configuration in appsettings.json.

[D-Inventor]

This issue has been solved in versions 10.4.0 and 13.1.0 for Umbraco 10 and 13 respectively. Since Umbraco 11 and 12 are STS and a higher LTS version is available, these versions won't receive an update anymore.

I'm closing this issue.