This question was created in reference to: [Horde suspect range with existing [Content removed]
Hello,
We found that matchers for Horde fingerprints are using the hashed fingerprint because the editor outputs structured logging, which prevents the matchers from working. This is explained well in the following answer:
[Content removed]
I understand the intention behind this behavior. However, the result is that even basic Horde use cases, such as running Unreal Editor Data Validation, output everything using hashed fingerprints.
This makes Horde issues messier than necessary.
Previously, I assumed this was handled in Epic by matchers such as the content matchers. However, because Horde defaults to
UE_LOG_JSON_TO_STDOUT=1, those matchers do not appear to work.
What is Epic currently using as fingerprints for content validation?
Do you have all editor errors and warnings logged as hash-based fingerprints, or is this handled in a non-public part of Epic’s tooling? Or do you run the editor with UE_LOG_JSON_TO_STDOUT=0?
We run UE_LOG_JSON_TO_STDOUT=1, but we’re also falling back to the HashedIssueHandler in most cases, simply because the Horde team isn’t able to proactively update all call sites to log event IDs.
We are actively working on solutions to improve this internally, but our interim internal recommendation to teams is the same we’ve given on EPS, to use event IDs in log messages where possible.
We’ve definitely run into these issues internally (large suspect ranges), and the scope of adding event IDs is one of the reasons that we’re working on an alternative solution.
Unfortunately, this is still experimental and under active development, and not yet in a state that can be shared.
One thing we’ve added in the 5.8 preview that might help is the ability to group issues by logging channel.
// globals.json: Globals > plugins: GlobalPluginsConfig > build: BuildConfig > issues: IssueConfig
{
"channelGroups": [
{
"channels": [
"AssetCheck"
]
}
//{
// Example of combining two, often related channels
// Note. issues will still be generated independently if needed and this only affects grouping
//"channels": [
// "LogExample2",
// "LogExample3"
//]
//}
]
}
Does this mean that, on your end, Horde issues originating from the Unreal Editor process also have very large suspect ranges and often merge into bigger issues without proper assignees?
Would not adding event IDs require modifying engine code in potentially hundreds of places?
We expected Horde issues to help us track warnings more effectively, automatically identify likely assignees, and notify them when a new issue is introduced. However, I am no longer sure whether those expectations were correct.
In our case, Horde issues often merge into larger, monolithic issues with long suspect ranges, which makes them difficult to assign to a single owner.
We will probably try to run without UE_LOG_JSON_TO_STDOUT because it looks like matchers can do the proper categorization automatically.
Thank you. It is helpful to know that you are facing similar challenges. We will review the WIP functionality, track the related work there, and consider running a few experiments.