NullReferenceException in ValidateFile

[Rockerby]

We had an issue this morning where our site stopped working with a NullReferenceException in the ValidateFile function. It was running yesterday and there have been no code / file changes since then (also no server updates or restarts). The ValidateFile function is pretty small so assuming that the file that it's passing in along the way is null. The bundle in question is a CSS bundle.

My gut is telling me this is something to do with the application pool going idle as a restart fixes the issue. Relevant stack trace extract below:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Smidge.BundleFileSetGenerator.ValidateFile(IWebFile file)
   at Smidge.BundleFileSetGenerator.GetOrderedFileSet(IEnumerable`1 files, PreProcessPipeline pipeline)
   at Smidge.BundleFileSetGenerator.GetOrderedFileSet(Bundle bundle, PreProcessPipeline pipeline)
   at Smidge.SmidgeHelper.GenerateBundleUrlsAsync(String bundleName, String fileExt, Boolean debug)
   at Smidge.TagHelpers.SmidgeLinkTagHelper.ProcessAsync(TagHelperContext context, TagHelperOutput output)
   at Microsoft.AspNetCore.Razor.Runtime.TagHelpers.TagHelperRunner.<RunAsync>g__Awaited|0_0(Task task, TagHelperExecutionContext executionContext, Int32 i, Int32 count)

For reference, this is an Umbraco 9.5.0 site (.NET 5), running Smidge 4.0.3 hosted on Windows Server 2019, IIS 10.

[nikro412956]

I have the same issue with the exact same conditions. It happened to 2 different websites so far. We might also need to report this to the Umbraco git repo so they can also look in to it.

[nikro412956]

@Rockerby What cache buster are you using? I am using the Timestamp cache buster. So i am curious which one you are using and if using the other cache buster can prevent this problem from occurring.

[Rockerby]

Hey @nikro412956 - this was using the Version cache buster type. I couldn't replicate this on a dev machine; purely on a live/staging environment.

[madsoulswe]

Yes, we got the same issue in production.

A couple of days ago the Igloo css-bundle returned 500 with the same exception. It was resoved after a restart. Now the js-bundle got the same issue.

The site is using Version-cachebuster and I have disabled Smidge MemoryCache for now to se if it helps.

Umbraco 10.5.1 + Smdige 4.5 Windows server

[benehudson]

For what it's worth this issue is still present as of Umbraco 13.5.1

I've been having 11.2 and 12.2 sites randomly crashing for over a year now. Restarting IIS fixes it every time. I thought the issue was Umbraco, so I upgraded several of my sites to 13.5.1 last week. I upgraded 5 sites before I could upgrade site number 6, the second site I upgraded to 13.5.1 crashed. I recently attended Umbraco US Festival and from talking to other devs no one I talked to seemed to be experiencing these same random crashes. So when my 13.5.1 site crashed I dug into the logs and it points at a null reference inside Smidge. I'm running on an Azure VM using Version cache buster as well.

[Shazwazza]

Is everyone reporting this issue occurring on your front-end or back office?

I'm trying to figure out how this could happen since it would mean that one of the file references for the bundle is null here https://github.com/Shazwazza/Smidge/blob/e022331d15c898c5876d4725004f746b3dfdcb05/src/Smidge.Core/BundleFileSetGenerator.cs#L113

The only way this could happen is if that file reference is null when creating the bundle initially.

Can anyone provide an example of how they are creating the bundle that is causing this issue? It could also occur if using view based declarations and RequireCss/RequireJs is used and passing in a null file.

I can add some null checks to these methods to try to avoid this.

[Shazwazza]

This is actually a duplicate of #205

[Shazwazza]

Have published version 4.5.0 https://github.com/Shazwazza/Smidge/releases/tag/v4.5.0 which eagerly adds null checks when creating a bundle with null files. Its not clear what the full underlying issue is but the file can only be null if it is registered as null when creating the bundle.

[benehudson]

@Shazwazza To answer your question I'm seeing this issue on the "front end". Smidge works great for me...most of the time. What happens in my case is everything is working just fine and it's running on my server then occasionally (not every time) when the w3wp.exe recycles I'll get a null reference exception 500 error after the recycle (which effectively brings down my entire site as I'm using Smidge in my master template). I've never seen it when developing locally, only have this rare but statically significant issue when my site is deployed on a server and immediately after a w3wp.exe recycle.

[Shazwazza]

@benehudson are you using view based declarations?

[benehudson]

@Shazwazza this is the code in my TemplateMaster.cshtml

SmidgeHelper
        .CreateJsBundle("inline-js-bundle")
        .RequiresJs("~/scripts/slick.js", "~/scripts/jquery.fancybox.js", "~/scripts/isotope.images.loaded.js", "~/scripts/isotope.js", "~/scripts/jquery.google.reviews.js", "~/scripts/gsap.js", "~/scripts/gsap.scrolltrigger.js", "~/scripts/template.js");

    SmidgeHelper
        .CreateCssBundle("inline-css-bundle")
        .RequiresCss("~/css/slick.css", "~/css/slick-theme.css", "~/css/jquery.fancybox.css", "~/css/umbraco.block.grid.css", "~/css/template.css");

Then I use the taghelper to render the bundles.

[Shazwazza]

@benehudson where do you use the taghelper? Is that within your TemplateMaster.cshtml or somewhere else? View based declarations can be problematic, see https://github.com/Shazwazza/Smidge/issues/198#issuecomment-1646155044

[benehudson]

@Shazwazza yes the taghelpers are in my TemplateMaster.cshtml When you say "pre-defined bundles", you're saying moving the create bundle to the program.cs?

[Shazwazza]

Yep, like this https://github.com/Shazwazza/Smidge?tab=readme-ov-file#pre-defined-bundles

[Rockerby]

I haven't seen this issue for ages, but I can confirm I was getting this in view based declarations too. To be quite honest; I always thought that was the "right" way to do it.

Thanks for the pointer to the docs.