Filed this as 5.7, but it affects at least as far back as 5.5.
We’re trying to get horde’s workflow and issue systems setup for our use but we’re running into a problem where asset log and other types of logs seem to all be emit as json log events natively, and as such log matchers in horde do not run and never assign a proper event id to those log events. This results in the content issue handler (and other handlers) not running, and only the hashed issue handler catching things like blueprint compile failures. The result is a blueprint compile error ends up spawning multiple issues (at least one per cook node, if not more) because the hashed issue handler does a much worse job of grouping these failures, and these issues do not surface the affected files as well.
As far as I can tell there’s nothing that will cause an AssetLog event to get a properly assigned event id as it is a structured log event and thus log event matchers don’t run on it. I’m pretty sure this affects most if not all other issue handlers as well, it’s just caused us the most problems when a blueprint compile fails.
Is this a missing feature? A configuration option were missing in our build pipeline somewhere? Something else?
Just to expand on this a bit from my investigation into why this is happening, it seems like horde’s ContentIssueHandler expects the following flow:
“Legacy” log event is emit in the format LogSomeCategory: Error: [AssetLog] Asset/Path.uasset: some error message here
LogEventParser runs each matcher on the log event
ContentEventMatcher parses out the information from the event and assigns it an event id of KnownLogEvents.Engine_AssetLog
ContentIssueHandler sees that it has an event id of Engine_AssetLog and pulls out the data it needs and groups the issue properly.
What seems to be actually happening:
Structured log event is emit (in the proper format, and with structured fields that match what ContentIssueHandler expects)
LogEventMatcher does *NOT* run any matchers on it, as structured json log events do not run matchers
The log event does not have any kind of event id
ContentIssueHandler ignores the event because it has an event id of KnownLogEvents.None
The same issue seems to happen with other types of log events, but this is the most common (and most annoying) we’ve encountered. It seems like either the engine should be tagging event ids itself instead of relying on automation to match against it (which is non-trivial for some event types like crashes which can come from a lot of places), or the LogEventMatcher needs to somehow support matching structured log events. It doesn’t look like either of these things are implemented right now but I’d be very happy to be wrong.
Alternatively, horde’s issue handlers need to be rewritten to support checking for structured events without an event id. For now I’m working on patching our internal build of horde to do this at least for content issues since they tend to be the most annoying, but an “official” answer would be appreciated.
Thank you for the detailed write-up and investigation. I’ve spoken with the Horde team, and I can confirm that it is by design that the matchers aren’t run against structured logging.
The philosophy behind the approach is that the system expects structured logging to be well-formed, and the matchers are for cases where we cannot control the format (e.g., from compilers).
The team recommends adding a new issue handler alongside ContentIssueHandler that provides the grouping logic you require and doesn’t rely on an Event ID.