Skip to content

fix(workflows): guard workflow execution polling state#1599

Open
guanghuang wants to merge 1 commit into
coleam00:devfrom
guanghuang:fix/workflow-execution-polling-state
Open

fix(workflows): guard workflow execution polling state#1599
guanghuang wants to merge 1 commit into
coleam00:devfrom
guanghuang:fix/workflow-execution-polling-state

Conversation

@guanghuang

@guanghuang guanghuang commented May 6, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Problem: The workflow execution route could crash during polling when React Query had partial query data without workflowState.
  • Why it matters: A long-running workflow monitor could be replaced by the error boundary and require a manual reload.
  • What changed: Guarded the nested polling status access and added an explicit missing-run error for malformed run detail responses.
  • What did not change (scope boundary): No workflow execution semantics, API schema, Caddy/auth behavior, or dashboard layout changes.

UX Journey

Before

User                   Web UI                         API
────                   ──────                         ───
opens workflow run ──▶ loads execution page ────────▶ GET /api/workflows/runs/:id
                       renders run state ◀────────── returns run/events
                       polling callback reads
                       data.workflowState.status
                       [partial query state]
                       throws TypeError
sees error page ◀───── error boundary replaces page

After

User                   Web UI                         API
────                   ──────                         ───
opens workflow run ──▶ loads execution page ────────▶ GET /api/workflows/runs/:id
                       renders run state ◀────────── returns run/events
                       polling callback reads
                       data.workflowState?.status
                       [partial query state tolerated]
continues viewing ◀─── page keeps rendering/polling

Architecture Diagram

Before

WorkflowExecution [~]
  ├─ useQuery(queryFn) ─────▶ getWorkflowRun ─────▶ /api/workflows/runs/:id
  └─ refetchInterval ──────▶ query.state.data.workflowState.status
                                └─ throws if workflowState is missing

After

WorkflowExecution [~]
  ├─ useQuery(queryFn) ─────▶ getWorkflowRun ─────▶ /api/workflows/runs/:id
  │                            └─ validates run payload exists
  └─ refetchInterval ──────▶ query.state.data.workflowState?.status
                                └─ tolerates partial query data

Connection inventory (list every module-to-module edge, mark changes):

From To Status Notes
WorkflowExecution getWorkflowRun unchanged Same API client call.
WorkflowExecution React Query refetchInterval modified Nested workflow state access is now guarded.
WorkflowExecution Error boundary unchanged Still handles real render errors; this polling edge should no longer trigger it.

Label Snapshot

  • Risk: risk: low
  • Size: size: XS
  • Scope: web
  • Module: web:workflow-execution

Change Metadata

  • Change type: bug
  • Primary scope: web

Linked Issue

Validation Evidence (required)

Commands and result summary:

bun --filter @archon/web type-check
# PASS

bun test packages/web/src/lib/select-initial-node.test.ts
# PASS: 5 tests
  • Evidence provided (test/log/trace/screenshot): The failing stack points to WorkflowExecution.tsx polling status access; the code now guards that path.
  • If any command is intentionally skipped, explain why: Full bun run validate was skipped because this is a one-line web route guard and focused type-check/test coverage was run.

Security Impact (required)

  • New permissions/capabilities? (No)
  • New external network calls? (No)
  • Secrets/tokens handling changed? (No)
  • File system access scope changed? (No)
  • If any Yes, describe risk and mitigation: Not applicable.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Database migration needed? (No)
  • If yes, exact upgrade steps: Not applicable.

Human Verification (required)

What was personally validated beyond CI:

  • Verified scenarios: Reproduced the reported stack location from the browser error, applied the guard, built and deployed the patched web bundle in a remote Archon instance.
  • Edge cases checked: Partial query state in refetchInterval; missing run response now throws a normal query error instead of causing nested property access failures.
  • What was not verified: Full browser automation test across all workflow execution pages.

Side Effects / Blast Radius (required)

  • Affected subsystems/workflows: Workflow execution detail page polling.
  • Potential unintended effects: Polling may continue for a malformed query state until a valid status is available, which is preferable to crashing the route.
  • Guardrails/monitoring for early detection: TypeScript type-check and browser console/error boundary behavior on workflow execution pages.

Rollback Plan (required)

  • Fast rollback command/path: Revert this commit.
  • Feature flags or config toggles (if any): None.
  • Observable failure symptoms: Workflow execution pages again showing the error boundary with Cannot read properties of undefined (reading 'status').

Risks and Mitigations

  • Risk: A malformed API response without run could still prevent the page from rendering that run.
    • Mitigation: The query now throws a clear missing-run error instead of dereferencing data.run and crashing unpredictably.

Summary by CodeRabbit

  • New Features

    • Added a utility that transforms workflow run and event responses into a frontend-ready execution state.
  • Bug Fixes

    • Prevented failures when workflow state is absent and improved polling/status derivation logic.
  • Tests

    • Expanded test coverage for workflow run shaping, node/loop/artifact handling, timestamps, and missing-run errors.
  • Chores

    • Test script extended to include the workflow execution tests.

Review Change Stack

@coderabbitai

coderabbitai Bot commented May 6, 2026

Copy link
Copy Markdown
📝 Walkthrough

Walkthrough

Centralize transformation of run+events into frontend state with buildWorkflowRunQueryData, update WorkflowExecution to use it and guard polling access, add unit tests for builder behaviors, and include the component test in the package test script.

Changes

Workflow run query builder & consumer

Layer / File(s) Summary
Builder imports & types
packages/web/src/lib/workflow-run-query.ts
Adds imports and the exported WorkflowRunQueryData type and internal WorkflowRunQueryResponse.
Node aggregation
packages/web/src/lib/workflow-run-query.ts
Scan node_* events to build DagNodeState map with status, duration, error, and reason.
Loop iteration augmentation
packages/web/src/lib/workflow-run-query.ts
Process loop_iteration_* events to insert/update LoopIterationInfo and track iteration indices.
Final assembly
packages/web/src/lib/workflow-run-query.ts
Compose workflowState (dagNodes, artifacts, timestamps via ensureUtc) and return WorkflowRunQueryData with platform IDs and raw events.
Consumer: WorkflowExecution
packages/web/src/components/workflows/WorkflowExecution.tsx
Replace inline payload construction with buildWorkflowRunQueryData(runId, data), remove local WorkflowRunQueryData type, and use optional chaining when deriving polling status.
Builder unit tests
packages/web/src/lib/workflow-run-query.test.ts
Add Bun tests covering missing-run error, empty events, node state derivation, stale start handling, loop iterations, artifact mapping, and timestamp/platform ID extraction.
Component test & package script
packages/web/src/components/workflows/WorkflowExecution.test.tsx, packages/web/package.json
Add WorkflowExecution component test and include it in the package test script.

Sequence Diagram

sequenceDiagram
  participant Client
  participant WorkflowExecution
  participant REST_API
  participant buildWorkflowRunQueryData
  Client->>WorkflowExecution: open execution page (runId)
  WorkflowExecution->>REST_API: fetch run + events
  REST_API->>WorkflowExecution: run + events response
  WorkflowExecution->>buildWorkflowRunQueryData: buildWorkflowRunQueryData(runId, data)
  buildWorkflowRunQueryData->>WorkflowExecution: WorkflowRunQueryData (workflowState, events, platform ids)
  WorkflowExecution->>Client: render execution UI
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related issues

Poem

🐰 I hop through code with nimble feet,
I gather events and make them neat.
Nodes and loops in tidy rows,
Polling guarded, status shows.
Tests applaud — a carrot treat! 🥕

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Out of Scope Changes check ❓ Inconclusive The PR introduces new modules (workflow-run-query.ts/test.ts) and refactors WorkflowExecution.tsx to use them, alongside test additions. However, the PR objectives note that reviewers requested removal of JSDoc comments and additional test coverage for the new modules, indicating scope boundary issues regarding code quality and test completeness. Clarify whether added JSDoc comments should be removed and confirm whether the new workflow-run-query module's test coverage (currently covering only query data building) adequately validates all behavioral branches, particularly loop iteration and artifact mapping logic.
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title 'fix(workflows): guard workflow execution polling state' directly matches the main change: adding optional chaining to guard against missing workflowState during polling.
Description check ✅ Passed The PR description is comprehensive, covering all template sections: problem statement, UX journey (before/after), architecture diagrams, validation evidence, security impact, compatibility, human verification, side effects, rollback plan, and risk mitigations.
Linked Issues check ✅ Passed The PR addresses the primary objective from #1598: guarding the nested polling state access with optional chaining and adding explicit error handling for missing run payloads. Code changes include the workflowState?.status guard and validation logic in the new helper module.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@guanghuang guanghuang force-pushed the fix/workflow-execution-polling-state branch from 08783c5 to b718114 Compare May 6, 2026 15:51

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
packages/web/src/components/workflows/WorkflowExecution.tsx (2)

61-61: 💤 Low value

Consider a named interface and tighter prop type for StatusBadge.

The inline { status: string } type is both broader than needed and not a named interface. The coding guideline prefers interface for object shapes, and narrowing to WorkflowRunStatus would catch accidental misuse at the call site.

♻️ Proposed refactor
+interface StatusBadgeProps {
+  status: WorkflowRunStatus;
+}
+
-function StatusBadge({ status }: { status: string }): React.ReactElement {
+function StatusBadge({ status }: StatusBadgeProps): React.ReactElement {

As per coding guidelines: "prefer interface for defining object shapes rather than type" and "Use strict TypeScript configuration with complete type annotations on all functions."

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/web/src/components/workflows/WorkflowExecution.tsx` at line 61,
Replace the inline prop type on StatusBadge with a named interface and tighten
the status type to the domain union: define an interface (e.g. StatusBadgeProps)
with status: WorkflowRunStatus and update the StatusBadge signature to function
StatusBadge(props: StatusBadgeProps): React.ReactElement (or destructure as
function StatusBadge({ status }: StatusBadgeProps)). Ensure WorkflowRunStatus is
the correct union/enum imported or declared in the same module.

212-216: 💤 Low value

Polling guard is correct for TanStack Query v5.

In v5, refetchInterval dropped the leading data parameter and now receives only the query object, with data accessible via query.state.data. The optional chain on data is necessary (undefined before the first successful fetch), and the extra ?. on workflowState is redundant from TypeScript's perspective but harmless as a runtime guard.

One minor point: the query parameter has no explicit type annotation. Under the strict-typing guideline this should be (query: Query<WorkflowRunQueryData, Error, WorkflowRunQueryData, ['workflowRun', string]>): number | false => ..., importing Query from @tanstack/react-query. In practice TypeScript infers this correctly from the useQuery context, so this is a style nit only.

As per coding guidelines: "Use strict TypeScript configuration with complete type annotations on all functions."

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/web/src/components/workflows/WorkflowExecution.tsx` around lines 212
- 216, The refetchInterval callback is missing an explicit type for its
parameter; update the arrow function signature for refetchInterval to annotate
the parameter as Query<WorkflowRunQueryData, Error, WorkflowRunQueryData,
['workflowRun', string]> (import Query from `@tanstack/react-query` and use the
existing WorkflowRunQueryData type) so the function becomes typed correctly
while keeping the existing access to query.state.data and the terminal-status
guard.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/web/src/components/workflows/WorkflowExecution.tsx`:
- Line 61: Replace the inline prop type on StatusBadge with a named interface
and tighten the status type to the domain union: define an interface (e.g.
StatusBadgeProps) with status: WorkflowRunStatus and update the StatusBadge
signature to function StatusBadge(props: StatusBadgeProps): React.ReactElement
(or destructure as function StatusBadge({ status }: StatusBadgeProps)). Ensure
WorkflowRunStatus is the correct union/enum imported or declared in the same
module.
- Around line 212-216: The refetchInterval callback is missing an explicit type
for its parameter; update the arrow function signature for refetchInterval to
annotate the parameter as Query<WorkflowRunQueryData, Error,
WorkflowRunQueryData, ['workflowRun', string]> (import Query from
`@tanstack/react-query` and use the existing WorkflowRunQueryData type) so the
function becomes typed correctly while keeping the existing access to
query.state.data and the terminal-status guard.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: dddc7ef7-7d69-4f91-b36d-ad356c80ae22

📥 Commits

Reviewing files that changed from the base of the PR and between 08783c5 and b718114.

📒 Files selected for processing (1)
  • packages/web/src/components/workflows/WorkflowExecution.tsx

@Wirasm

Wirasm commented May 11, 2026

Copy link
Copy Markdown
Collaborator

Review Summary

Verdict: blocking-issues

Your PR fix for React Query polling edge cases in WorkflowExecution.tsx is correct — both the null guard on data.run and the optional chaining on workflowState?.status are necessary and sound. However, three JSDoc comments were added that restate what the function names already convey. Per CLAUDE.md, default to no comments unless the WHY is non-obvious.

Blocking issues

  • WorkflowExecution.tsx:40-41 — Remove the JSDoc on isTerminal. The function name already says "is terminal" — the comment adds nothing.
  • WorkflowExecution.tsx:58-59 — Remove the JSDoc on StatusBadge. "Standard execution page badge colors" references a UI convention that will rot when the design system changes.
  • WorkflowExecution.tsx:76-77 — Remove the JSDoc on WorkflowExecution. "Backed by REST snapshots and SSE updates" is implementation detail that will rot.

Suggested fixes

  • WorkflowExecution.tsx:109 — Add a test for the new if (!data.run) throw new Error(...) path. Verify that when the REST response lacks a run record, the query re-throws with a message containing the runId. (Existing integration-level tests cover the ?.status fix transitively.)

Minor / nice-to-have

  • WorkflowExecution.tsx:42isTerminal() lacks a direct unit test. Low priority since isTerminalStatus() is the canonical public utility and existing tests cover it transitively.

Compliments

  • Clean, focused fix touching one file. Both null-safety guards are correct and the scope is tight.
  • The explicit throw with runId traceability is a solid pattern for a frontend component with no access to structured logging.
  • PR template is thorough with specific validation evidence and rollback plan.

Reviewed via maintainer-review-pr workflow (Pi/Minimax). Aspects run: code-review, error-handling, test-coverage, comment-quality.

@guanghuang guanghuang force-pushed the fix/workflow-execution-polling-state branch from b718114 to 77beac4 Compare May 11, 2026 19:13
@Wirasm

Wirasm commented May 13, 2026

Copy link
Copy Markdown
Collaborator

Review Summary

Verdict: minor-fixes-needed

The refactoring cleanly extracts buildWorkflowRunQueryData into a testable module and the crash guard fix is correct. However, the new query builder function has significant test coverage gaps — the core logic (node status mapping, loop iteration enrichment, artifact mapping, timestamp computation) is untested beyond the error-throw path.

Suggested fixes

  • packages/web/src/lib/workflow-run-query.ts:16–128: buildWorkflowRunQueryData() has 4 behavioral branches with no tests:

    1. Node status derivation (node_startedrunning, etc.) and dagNodes array construction
    2. loop_iteration_* enrichment for currentIteration / maxIterations / iterations
    3. workflow_artifact events → artifacts array
    4. startedAt / completedAt timestamp computation

    Add grouped tests for each branch. Suggested cases include: node status mapping, duplicate node event resolution, nodeId extraction fallback (the event.data.nodeId as string cast), loop iteration population and updates, artifact mapping and filtering, timestamp computation from run.started_at/run.completed_at, and platform ID null coalescing.

  • packages/web/src/components/workflows/WorkflowExecution.tsx:91: The ?. guard on workflowState in refetchInterval handles partial React Query data. Add a component-level integration test that verifies the component renders gracefully when workflowState is undefined.

Minor / nice-to-have

  • packages/web/src/lib/workflow-run-query.test.ts:5: Test file uses describe + test (bun:test) while other PR test files use describe + it. Use it for consistency.

Compliments

  • The optional chaining guard (workflowState?.status) is minimal and targeted — exactly the right fix for the React Query partial-state crash.
  • The error-throw test for the missing run case is a solid start and sets a good precedent for the remaining test coverage.

Reviewed via maintainer-review-pr workflow (Pi/Minimax). Aspects run: code-review, error-handling, test-coverage.

@Wirasm

Wirasm commented May 14, 2026

Copy link
Copy Markdown
Collaborator

Review Summary

Verdict: minor-fixes-needed

The extraction of buildWorkflowRunQueryData into its own module is a clean, well-scoped refactor. Error handling is solid (fail-fast with actionable runId), type imports are correct, and the new optional chaining on workflowState is a genuine improvement over the original. The one issue: the extracted function is now a pure, unit-testable module with only one test covering the null-guard error path — ~90% of the branching logic (node statuses, loop iterations, artifact mapping, platform IDs) has no test coverage. A handful of focused tests would make this merge-ready.

Blocking issues

(none — no CRITICAL findings)

Suggested fixes

  • packages/web/src/lib/workflow-run-query.ts: Add tests for the extracted buildWorkflowRunQueryData logic. The current test file has only the null-guard case. Suggested coverage:
    1. node_startednode_completed for the same nodeIdstatus === 'completed', duration/error fields populated.
    2. node_failed event → status === 'failed', error populated.
    3. Unrecognized node_* event type → status === 'skipped'.
    4. Latest-non-running-wins: pass node_started then node_completed (same nodeId) → final status is completed. Add reverse-order variant.
    5. Events missing both step_name and data.nodeId → no entry in dagNodes.
    6. Loop iteration events (loop_iteration_started/completed/failed) alongside node_startedcurrentIteration, maxIterations, and nested iterations array on DagNodeState.
    7. workflow_artifact events with artifactType, label, url, pathartifacts array populated; entries with empty fields filtered out.
    8. run.completed_at === nullworkflowState.completedAt === undefined.
    9. Platform ID fields (workerPlatformId, parentPlatformId, conversationPlatformId, codebaseId) correctly extracted from data.run.
    10. Empty events array → both dagNodes and artifacts are empty.

Minor / nice-to-have

  • packages/web/src/lib/workflow-run-query.ts (iteration logic): Test the duplicate-iteration case — two loop_iteration_started events for the same iteration should overwrite (not duplicate) the entry in the iterations array.
  • packages/web/src/lib/workflow-run-query.ts (interface): Add a one-line comment above WorkflowRunQueryResponse explaining why run is nullable (// run is null when React Query is in loading/error state before data resolves.).
  • WorkflowExecution.tsx:97: Consider adding a test comment or integration test validating that the optional chaining on workflowState does not crash on first render when workflowState is undefined.

Compliments

  • The new runId parameter makes the error message actionable and far easier to debug than the previous implicit failure.
  • Test file placement (workflow-run-query.test.ts colocated with the module) follows project conventions well.
  • The comment on WorkflowToolCallEvent (line 36) explains the data source and display context concisely — exactly the kind of comment that adds value without restating the code.

Reviewed via maintainer-review-pr workflow (Pi/Minimax). Aspects run: code-review, error-handling, test-coverage, comment-quality.

@guanghuang guanghuang force-pushed the fix/workflow-execution-polling-state branch from 77beac4 to 01257d6 Compare May 15, 2026 20:06

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
packages/web/src/lib/workflow-run-query.test.ts (1)

5-5: ⚡ Quick win

Consider resetting the global event counter per test.

The global eventSequence variable is mutated across tests (incremented on line 29), which reduces test isolation. While the tests don't currently assert on specific ID values, this pattern could cause order-dependent behavior or confusion during debugging.

♻️ Suggested fix
 let eventSequence = 0;

+describe('buildWorkflowRunQueryData', () => {
+  beforeEach(() => {
+    eventSequence = 0;
+  });
+
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/web/src/lib/workflow-run-query.test.ts` at line 5, The file-level
mutable variable eventSequence is shared across tests and should be reset before
each test to preserve isolation; add a beforeEach hook in
workflow-run-query.test.ts that sets eventSequence = 0 so every test starts with
a fresh counter, ensuring mocks that use eventSequence++ (the incrementing
usage) produce predictable IDs per test.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/web/src/lib/workflow-run-query.test.ts`:
- Line 5: The file-level mutable variable eventSequence is shared across tests
and should be reset before each test to preserve isolation; add a beforeEach
hook in workflow-run-query.test.ts that sets eventSequence = 0 so every test
starts with a fresh counter, ensuring mocks that use eventSequence++ (the
incrementing usage) produce predictable IDs per test.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: d834c0a6-26dc-4be6-a4a9-b458146e1514

📥 Commits

Reviewing files that changed from the base of the PR and between 77beac4 and 01257d6.

📒 Files selected for processing (5)
  • packages/web/package.json
  • packages/web/src/components/workflows/WorkflowExecution.test.tsx
  • packages/web/src/components/workflows/WorkflowExecution.tsx
  • packages/web/src/lib/workflow-run-query.test.ts
  • packages/web/src/lib/workflow-run-query.ts
🚧 Files skipped from review as they are similar to previous changes (2)
  • packages/web/src/lib/workflow-run-query.ts
  • packages/web/src/components/workflows/WorkflowExecution.tsx

@kagura-agent

Copy link
Copy Markdown
Contributor

Thanks for the thorough review @Wirasm! You're right that the test coverage for buildWorkflowRunQueryData is thin — only the null-guard path is tested. I'll add tests covering node status mapping, loop iteration enrichment, artifact mapping, and timestamp computation. Will push a follow-up commit shortly.

@Wirasm

Wirasm commented May 27, 2026

Copy link
Copy Markdown
Collaborator

@$guanghuang related to #1578 — overlapping area or partial fix.

@Wirasm

Wirasm commented May 27, 2026

Copy link
Copy Markdown
Collaborator

@$guanghuang related to #1598 — overlapping area or partial fix.

@Wirasm

Wirasm commented May 27, 2026

Copy link
Copy Markdown
Collaborator

@$guanghuang related to #1578 — overlapping area or partial fix.

@Wirasm

Wirasm commented May 27, 2026

Copy link
Copy Markdown
Collaborator

@$guanghuang related to #1598 — overlapping area or partial fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Workflow execution page can crash during polling

3 participants