fix: handled non-matched ems events

[Hardikl]

Testing,
Case 1: when below order ems generated in sub sequent polls, then first ems retained in global e.Matrix cache and second is not valid so it won't add any new instance to existing matrix. No changes in this workflow.

{
    "message-name": "hm.alert.raised",
    "values": [1,2,"RaidLeftBehindAggrAlert",4,5,6,7,8,9,10,11,12,13,14]
}

{
    "message-name": "hm.alert.raised",
    "values": [1,2,3,4,5,6,7,8,9,10,11,12,13,14]
}

Case 2: when below order ems generated in sub sequent polls, then first ems is not valid and not matched and deleted from e.Matrix and second is valid so added in global e.Matrix cache as-is. Fix is targeting this workflow.

{
    "message-name": "hm.alert.raised",
    "values": [1,2,3,4,5,6,7,8,9,10,11,12,13,14]
}

{
    "message-name": "hm.alert.raised",
    "values": [1,2,"RaidLeftBehindAggrAlert",4,5,6,7,8,9,10,11,12,13,14]
}

[Copilot]

Pull request overview

Fixes EMS matrix-cache behavior when an EMS record is received for a message name but does not match any configured matches filters, ensuring the collector doesn’t retain an empty/invalid matrix entry that can interfere with later valid events.

Changes:

• Track whether an EMS matrix already existed vs. was newly created during HandleResults.
• When an EMS record does not match any configured props, remove the instance and additionally delete the matrix entry if it was newly created for that non-matching record.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.