"thread blocked indefinitely in an MVar operation" errors

[dbp]

I assume this is a regression from #844.

I have an old site that I haven't changed for years and years. I recently, due to CI updates, had to update it to current Hakyll/GHC 9.4, getting this new runtime.

Despite runing with only one thread ("Using async runtime with 1 threads..."), it seems like the order that pages are generated has changed. This is causing intermittent errors (presumably there are dependencies that were implicit, which previously was fine, since the order pages were created used to correspond to the order in file, and now presumably is due to the graph sorting for new runtime). Both calls to error (which are now happening because pages are not generated in the right order) and, it seems, some other causes I don't understand, can cause these MVar locking errors.

Running again on the same site (which thus partly generated) will succeed, or maybe after several blocked runs will succeed. This doesn't really work for CI (and is pretty sloppy regardless).

Is there a way to run without this new async runtime (which from the PR, looks like it got pretty minimal testing before merging...)? There is a reason why this site of mine hasn't been changed in years; I really don't have the time/budget to significantly debug/rewrite it.

[jaspervdj]

Is there any chance the site is open source so we could reproduce this?

Most dependencies should be tracked implicitly already in Hakyll, so I think it’s more likely that rules could be overwriting each other like in #1000 (even though a check was added for that).

[dbp]

It's probably fine for it to be public -- https://github.com/dbp/lydiajohnston -- I don't think the same file is written multiple times, but it does some dynamic stuff, as there is a .yml file that controls metadata for the whole site...

[jaspervdj]

Thanks! I was able to reproduce the bug now.

[jaspervdj]

I couldn't find anything wrong with the dependencies in that site. Chasing down the error message that appeared in the log, Missing Sea Glass, I found I could fix the build with:

diff --git a/pages/1.yml b/pages/1.yml
index f2ff7f6..4a6823e 100644
--- a/pages/1.yml
+++ b/pages/1.yml
@@ -1,7 +1,7 @@
 paintings:
 - id: Arise
   price: $1450, Oil/Cold Wax on Panel, Framed
-- id: Sea Glass
+- id: Sea_Glass
   price: $1450, Oil/Cold Wax on Panel, Framed

 - id: Trading_Whisper

I suspect this was also an error in the old runtime, which (wrongly) ignored it.

It's still a bit of a problem that calling error can cause a thread blocked indefinitely in an MVar operation issue, that is very misleading and needs to be fixed.

[dbp]

What's interesting (you're right, of course) is that with the new runtime, running it multiple times seems to get past the error, which is strange. Maybe it partly creates the file, and then as a result doesn't re-run the (failing) job? I guess that might have been the case in the past too (I'm not sure if I would have re-run something given the error).

[jaspervdj]

I'm going to close this, as #1015 will stop execution and make it more obvious when an error is encountered, so it should prevent similar issues going forward.