Horde "ScopedIssueHandler" conflicts with structured logging property names generated by engine ("channel" vs. "_channel")

Development Pipeline & Plugins
, ,
1

The `ScopedIssueHandler` in Horde expects “properties.channel” from the event’s JSON data to correctly process it as “Scoped:<channel_name>”, but structur-ified log lines from the engine when `UE_LOG_JSON_TO_STDOUT` is enabled get property names like “_channel” and “_severity” instead. Even after verifying “ScopedIssueHandler” is enabled on the workflow, this mismatch causes it to fail handling these events as expected, and they fall back to being “Hashed” instead.

I’m essentially curious if this was intended and has a suggested workaround, or an oversight we could address on our end by modifying “ScopedIssueHandler” to also recognize the alternate spelling.

[Attachment Removed]

2

Rough Steps to Reproduce

  1. Ensure a workflow configuration exists with the “Scoped” issue handler enabled: `“issueHandlers”: [ “Scoped” ]`.
  2. Run a job who’s template uses the workflow from #1 which is known to print errors and/or warnings in the engine’s log category/severity/etc. format.
  3. Verify the environment variable `UE_LOG_JSON_TO_STDOUT` was enabled during execution via the Horde log (this seems to have always been the default on our end).
  4. Verify the issues created by the build are fingerprinted as “Hashed” and not “Scoped: <channel>”.
    [Attachment Removed]
3

Hi Garrah, thank you for the detailed report. I have raised a bug report on this.

A possible working around to modify the source your end could be in ScopedIssueHandler.cs:43, try properties._channel.* first and fall back to properties.channel.*, mirroring what HashedIssueHandler already does.

Matthew

[Attachment Removed]

4

Thank you Matthew! This solution has been implemented and deployed on our end for approximately a week and appears to be working as expected.

Garrah

[Attachment Removed]

5

Hi Garrah, that is great news. I will close this ticket.

Matthew

[Attachment Removed]