Extend Workflow Event Types filter functionality to filter Workflow Signaled events

[adhityamamallan]

Summary

The "Signal" value in the Workflow Event Types filter currently filters for ExternalWorkflowExecutionSignaled event groups. However, since filtering for workflow signals is much more common, it is easy to assume that the "Signal" value filters for those. This PR modifies the event filtering so that "Signal" actually filters for workflow signals.

Changes:

• Extend Workflow Event Types filter to accept custom functions that run on a history events group
• Create workflowHistoryFilterTypesConfig that modifies the current filtering logic to show workflow signals under the "Signal" filter
• (unrelated) Show signal name and input in the event summary
• (unrelated) Fix typo: is-signle-event.test-ts -> is-single-event.test.ts

Test Plan

Added/updated unit tests + ran locally.

[Copilot]

Pull Request Overview

This PR creates a separate history events group for workflow signals to improve filtering accuracy. Previously, the "Signal" filter incorrectly filtered for external workflow execution signals instead of workflow signals, which are more commonly filtered for.

• Create new WorkflowSignaled event group type for workflow signal events
• Update filter mapping so "Signal" filters for workflow signals instead of external workflow signals
• Move external workflow signals to the "Workflow" category

Reviewed Changes

Copilot reviewed 16 out of 16 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
workflow-history.types.ts	Adds new WorkflowSignaled group type and moves workflowExecutionSignaledEventAttributes from single events
workflow-history-filters-type.constants.ts	Updates filter mapping to use WorkflowSignaled for Signal filter
group-history-events.ts	Adds grouping logic for workflow signaled events
get-workflow-signaled-event-group-from-events.ts	Creates new group handler for workflow signaled events
get-single-event-group-from-events.ts	Removes workflow signaled event handling
is-workflow-signaled-event.ts	New type guard for workflow signaled events
is-single-event.ts	Removes workflow signaled event from single events list
Various test files	Updates tests to reflect new grouping structure
Various fixture files	Creates new fixtures and updates existing ones for workflow signaled events

Comments suppressed due to low confidence (1)

src/views/workflow-history/workflow-history.types.ts:1

• The HistoryEventGroupType union type is missing the new 'WorkflowSignaled' type that was added in the WorkflowSignaledEventHistoryGroup definition. This creates an inconsistency between the type definition and its usage.

import { type z } from 'zod';

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Assem-Uber]

@adhityamamallan Why are we changing the signal from a single event to a group ?
Groups are for cases were we have multiple events showing together and have related status. I assume we can still fix the filtration issue with keeping it as a single event.

[Assem-Uber]

Treating SignalExternalWorkflowExecution as workflow event can also be confusing in the existence of Signal filter.

For example Child workflow events would make sense to be under workflow if we don't have CHILDWORKFLOW group. But since we have it is confusing to have them under WORKFLOW.

[adhityamamallan]

I assume we can still fix the filtration issue with keeping it as a single event.

Unfortunately not; the filtering is effective only on groups (workflow-history.tsx#L175).

Treating SignalExternalWorkflowExecution as workflow event can also be confusing in the existence of Signal filter.

I agree. I initially had a separate filter value for it, but could not figure out what to call it, because having "Signal" and "External Workflow Signal" together is confusing. Any suggestions for what to call it?

On another note, the "Workflow" group is a little problematic because we include all single events under it, regardless of what they are. And it's not entirely clear to users what they are, either. IMHO, the more clarity we bring to single events, the better, even if it means breaking the category up into different, more granular categories.

[Assem-Uber]

Signal looks descriptive, it can indicate outgoing/incoming signal.

On another note, the "Workflow" group is a little problematic because we include all single events under it
Oh good catch, that is also problematic.

I see that as problematic as the signals, so better solve it once than working around it. We have this method that should give the flexibility we need.

Having a set of filter groups that have Custom filtration logic would solve the issue (Those can be tracked in a map). For example Signal filter can be marked as Custom and it matches groups with SignalExternalWorkflowExecution type or group with event type Event with event (workflowExecutionSignaledEventAttributes). This should solve the issue and allow solving the issue you pointed above.

[Copilot]

Pull Request Overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

src/views/workflow-history/workflow-history-filters-type/workflow-history-filters-type.types.ts:13

• The 'DECISION' type is duplicated in the union type. Remove one of the duplicate entries.

  | 'DECISION'

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[adhityamamallan]

This was unintentional because of the renaming, but I still think the new order makes more sense