Hi Bernard

Have you raised this on the Issue Tracker?

https://github.com/umbraco/Umbraco-CMS/issues

The Redirect Url Manager is quite a simplistic implementation, that I don't think is designed to handle every scenario 'yet'- and this sounds like an issue in the way the Redirect Url Manager determines what the 'actual' published url of the page was, when a change is made...

The redirects are created in the RedirectTrackingEventHandler

https://github.com/umbraco/Umbraco-CMS/blob/2f74720c38e734f359cdd3e9a7556860fb96801f/src/Umbraco.Web/Routing/RedirectTrackingEventHandler.cs

  private static void CreateRedirect(int contentId, Guid contentKey, string oldRoute)
        {

            var contentCache = GetPublishedCache();
            if (contentCache == null) return;

            var newRoute = contentCache.GetRouteById(contentId);
            if (IsNotRoute(newRoute) || oldRoute == newRoute) return;
            var redirectUrlService = ApplicationContext.Current.Services.RedirectUrlService;
            redirectUrlService.Register(oldRoute, contentKey);
        }

This event is triggered when the cache is updated:

private void PageCacheRefresher_CacheUpdated(PageCacheRefresher sender, CacheRefresherEventArgs cacheRefresherEventArgs) { // only on master / single, not on replicas! if (IsReplicaServer) return;

    // simply getting OldRoutes will register it in the request cache,
    // so whatever we do with it, try/finally it to ensure it's cleared

    try
    {
        foreach (var oldRoute in OldRoutes)
        {
            // assuming we cannot have 'CacheUpdated' for only part of the infos else we'd need
            // to set a flag in 'Published' to indicate which entities have been refreshed ok
            CreateRedirect(oldRoute.Key, oldRoute.Value.Item1, oldRoute.Value.Item2);
        }
    }
    finally
    {
        OldRoutes.Clear();
        RequestCache.ClearCacheItem(ContextKey3);
    }
}

The OldRoutes property is a dictionary containing the routes of an item through the publishing process,

var oldRoutes = RequestCache.GetCacheItem<>

this collection of 'OldRoutes' is populated during the ContentService_Publishing event: (eg before the published urls change, you need to know what they once were!)

foreach (var entity in entities)
        {
            // for each entity, we want to save the 'old route' of any impacted entity.
            //
            // previously, we'd save the routes of all descendants - super safe but has an
            // impact on perfs - assuming that the descendant routes will NOT change if the
            // entity's segment does not change (else... outside of the scope of the simple,
            // built -in, tracker) then we can compare the entity's old and new segments
            // and avoid processing the descendants

            var process = true;
            if (Moving == false) // always process descendants when moving
            {
                // SD: in 7.5.0 we re-lookup the entity that is published, which gets its
                // current state in the DB, which we use to get the 'old' segment. In the
                // future this will certainly cause some problems, to fix this we'd need to
                // change the IUrlSegmentProvider to support being able to determine if a
                // segment is going to change for an entity. See notes in IUrlSegmentProvider.

                var oldEntity = ApplicationContext.Current.Services.ContentService.GetById(entity.Id);
                if (oldEntity == null) continue;
                var oldSegment = oldEntity.GetUrlSegment();
                var newSegment = entity.GetUrlSegment();
                process = oldSegment != newSegment;
            }

            // skip if no segment change
            if (process == false) continue;

            // else save routes for all descendants
            var entityContent = contentCache.GetById(entity.Id);
            if (entityContent == null) continue;
            foreach (var x in entityContent.DescendantsOrSelf())
            {
                var route = contentCache.GetRouteById(x.Id);
                if (IsNotRoute(route)) continue;
                var wk = UnwrapToKey(x);
                if (wk == null) continue;

                OldRoutes[x.Id] = Tuple.Create(wk.Key, route);
            }
        }

So it is using the UrlSegmentProvider implementation to detect the change in url segment for a node that would trigger the creation of redirects, and populates the 'OldRoutes' dictionary once publishing is confirmed, (and the cache is updated to avoid creating redirects when publishing fails), it then creates the redirects - but it isn't, I don't think considering any CustomUrlProvider implementation...

So I would suggest raising it as an issue so it can be discussed as the best way to handle this scenario, or in case I've misunderstood!

In the meantime, 'you could' perform the same trick / use the same pattern of creating your own handling of the ContentServicePublishing Event, determine if a Url will change based on your CustomUrlProvider logic, and then triggering the creation of the Redirect by your own handling of the PageCacheRefresherCacheUpdated event

regards

Marc