V17 - Corrupt Cache due to Markdown (?) - Load balanced site - Editor Push Published uSync page and other pages went missing

Last night an editor push published a new page and then found that the site half went down. Lots of pages errored and the logs filled with exceptions.

I’m going through it now and piecing together what happened when but I am seeing lots of exceptions in the run up this around the Markdown editor (which is used heavily in this site).

The other weird thing is errors with corrupted URL paths. E.g. a page that would be /news/some-article. Is in the logs as unavailable /some/unrelated/section/some-article.

Throwing the exception into Claude and it suggests there’s a thread safety issue with how the value convertor deals with it’s dictionary of internal links in multiple threads. It’s rather confidently telling me this can lead to cache corruption and is fixed in v18 as the markdown us changing from HeyRed to Markdig and this will solve all my problems (I am cautious as I was asking Claude about an unrelated issue with the Markdown editor so it might be a bit keen to jump here). It has also confidently spat out solutions - the most attractive looking like a simple change to apparently make the convertor threadsafe…

CLAUDE SUGGESTION:
Option B: keep HeyRed, but make it thread-safe. This gives output identical to what you have now. Creating an instance costs little, but if you want to avoid that, a [ThreadStatic] or ThreadLocal<Markdown> works too.

ed.MarkdownSharp;
using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Core.Strings;

public class ThreadSafeHeyRedMarkdownToHtmlConverter : IMarkdownToHtmlConverter
{
    public string ToHtml(string markdown) => new Markdown().Transform(markdown);
}

public class MarkdownToHtmlComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
        => builder.Services.AddUnique<IMarkdownToHtmlConverter, ThreadSafeHeyRedMarkdownToHtmlConverter>();
}

A full release seemed to clear up the problem (which Claude does also not without prompt) so I believe it was likely cache corruption and the push publish just tipped it over the edge… The admin controller site in the load balancing setup was serving the pages without issue when I tried them.

Has anyone run into either / this issue (the markdown exceptions could be a red herring here)?

As I read that back the exceptions related to unavailable links in the wrong place makes perfect sense with the internal dictionary of the markdown editor going rouge…

I’ll see if I have these exceptions building up already today and test Uncle Claudes two suggestions locally. It’s confidently telling me this needs patching in v17 core and I should raise an issue but seems odd nobody else would have run up against this (or are we weird for using the Markdown editor in 2026?)

I’m not sure it’s weird, but I can’t recall every using the Markdown editor in my 15 years of Umbraco experience :smiley:

Hi @cheeseytoastie

I think the best case in this scenario is to try and recreate the problem on a simple Umbraco site that simulates multiple users and threads to see if this is actually the issue or whether Claude is being over optimistic with it’s solution.

If you can recreate it and this is a valid problem and the fix is sound, then you can raise an issue or PR to get it put into v17.

If Claude is just making this up, then at least you know that’s not the issue and it is something else that has caused it.

Justin

It’s from a solution I inherited - the editors seem to love it.

I think it was used because the original devs were given a front end and needed to inject custom classes on to each p, h1, h2,h3 element. They must have seen a danger in too much freedom with an RTE…

But it’s slowly been replaced with the RTE but the editors keep using the markdown!

Yes - on production I would expect to see this again - which this morning I haven’t. Though it might be due to publishing. I’ll have to recreate the stage → load balanced live setup to check fully I think.

So I’m not sure how to recreate it because I don’t know the order of events to cause the corruption to recreate. Was hoping my symptoms might trigger a “oh we had / have that problem” response to get more clues.

Hi @cheeseytoastie

Do the logs give any clues from timings or error messages? Can you cross reference that to users that were logged in and making changes and look at the site traffic at that time as load may make a difference.

It may be a hard one to replicate.

Justin