We have a client who creates articles during the week, saving each and setting it to publish on the upcoming Wednesday at 1:45 pm. Usually, they create between 2 and 6 articles a week.
When the articles are published, occasionally some are unroutable, with no URL.
This document is published but its URL cannot be routed
Umbraco v17.5.2
Publishing the article manually fixes it.
Rescheduling the article to be published fixes it (the one time I tried)
Reload Memory Cache / Rebuild Database Cache dos NOT fix it.
Pages published being scheduled are individual pages without children, all under a 2026 parent.
The logs don’t show anything I think is relevant apart from:
Each time a batch of scheduled publishing occurs, there is one error afterwards about a custom content finder we built, but this seems to occur regardless of the URL issue, so probably not relevant.
So far this has been reported regarding 2 groups/weeks
In each, the first article was fine, and the subsequent ones were unrouteable. (coincidence?)
Can anyone suggest any troubleshooting ideas?
NB: when I try and replicate the issue I can’t get it to occur
I’m suspecting something is funky with url routing elsewhere in the code beyond scheduled publishing as I am noticing, upon a content sync via Deploy on Cloud(u17.5.3), already published pages being marked with the same 'unrouteable` messaging after the Deploy.
That is, an already routable page with an active URL on the site has a content sync via deploy which then makes the page unpublished because it is marked with the ‘unroutable’ note - then requiring a manual republish to restore the URL that was previously working.
I’m not trying to pollute or distract from the immediate topic raised, though want to note my suspicion there may be something similar/related at a deeper level that needs attention. I’ve got some concerns about upcoming launches with this sort of behaviour where publishing is not 100% trustworthy.
I cannot tie in any specific doctype or other pattern which is a bit frustrating.
I you think there is an underlying issue and it’s not related to your code or third-party packages, then please feel free to raise it as an issue on the Umbraco issue tracker. That way, other’s can comment as well.
It would help if you have anything tangible or reproduceable, but if not then at least it gives you a starting point to discus this further with HQ.
It is not in umbraco Cloud, it’s a VM in a locally based cloud provider.
We have seen 3 of the last 6 documents suffer this issue.
only one particular doctype has been observed
I don’t think it’s validation as simply re-scheduling or publishing manually fixes it.
The affected pages do have a lot of content, so in our test env, I unpublished 20 older examples and they all scheduled published fine.
Prod has 5 new pages scheduled for 17th, so I’ll make a copy of prod DB and restore into test env and see if each behave the same for the next batch (probably all will work )
Hopefully linking these two provides the spark to get a productive starting point in place to diagnose the routing issues. It sounds like there are a number of different paths that people are running into the issue - so a common spot like DocumentUrlService does seem like a common point that could be at the heart of this mystery.
An inconclusive update. (I’m not sure that 17.6 really fixes the issue but we’ll get it deployed soon and see how that goes.)
I copied the DB from prod into 2 test environments, there were 6 scheduled documents to publish.
one test environment I had updated to 17.6.0 the other is 17.5.2 prod is 17.5.2
in the test environments, the 17.6 environment worked, and the 17.5.2 did not all failed to get a url, but in prod everything worked (this time)
Also discovered a case where another page of a different doctype was scheduled and published to end up without a URL. this was a shorter page unlike some of the others which are very long (sometimes 50 pages)
DECLARE @DocGuid uniqueidentifier = '__myguid__';
SELECT
n.id AS nodeId,
n.uniqueId,
n.text AS nodeName,
du.urlSegment,
du.isDraft, -- 0 = published url, 1 = draft url
du.isPrimary
FROM umbracoNode n
LEFT JOIN umbracoDocumentUrl du
ON du.uniqueId = n.uniqueId
WHERE n.uniqueId = @DocGuid
ORDER BY du.isDraft, du.isPrimary DESC;
The working environment shows 2 identical results, except one isDraft = 0 and one isDraft=1
The failed environment shows one result with isDraft=1
I thought I’d do another test, restored the DB backup I took last week onto the 17.6 environment, and this time it failed to get a url for all the scheduled pages, but the DB record did get created so I restarted it and they showed up. I think this is an adjacent issue, I think my main issue is the DB record not being created … sometimes.
I thought I’d do yet another test, this time I only get isDraft=1 records in the DB, but all 6 pages are the same again
)