@MetRonnie - I think that I fixed it.

The original approach (adding messages to the activity log file and checking for them later seemed to break some of the workflow restart tests in ways that make me un-confident that they are safe changes.

Scraping the log is horrible.

Next thing to try: using the database - this isn't straightforward, because the database doesn't contain a table which would easily contain the task messages.

Update: closed that as it does not seem feasible without a major refactor

Not entirely surprised, but thank you for attempting it.

@oliver-sanders are you waiting on me to do something with this?

Kinda, but I need to take a closer look. I think this isn't skipping enough of the method, the problem is about more than just logging, e.g. it appears to running event handlers and spawning logic for duplicate messages? But I know that when you tried moving the return higher up the function it caused problems.

I've had another look at this recently, and the notes on Matt Shin's original logic says

       # Unhandled messages. These include:
       #  * general non-output/progress messages
       #  * poll messages that repeat previous results
       # Note that all messages are logged already at the top.

https://github.com/cylc/cylc-flow/pull/2157/files

So it looks like Matt intended to have it work more simply than this and it's broken at some point. I'm going to reexamine this. :)