What's broken
When a step finishes with exit_reason = "kill" and error_type = "StateTooLargeError", the runs UI crashes with a CaseClauseError while rendering the step icon. The project history page and the run detail page both fail on render whenever they include such a step. Workflow execution itself is unaffected. Only the rendering breaks.
The crash is in LightningWeb.RunLive.Components.step_icon/1, which has explicit clauses for SecurityError, ImportError, TimeoutError, and OOMError, but no clause for StateTooLargeError and no catch-all.
The same mapping is mirrored in the React StepIcon used by the collaborative editor (assets/js/collaborative-editor/components/run-viewer/StepIcon.tsx). It has a gray ellipsis fallback so it doesn't crash, but it renders the killed step as "pending", which is misleading.
How it surfaced
Sentry on v2.16.2, both alerts from a single project that hit the new StateTooLargeError exit type from the worker:
What to fix
Two things, in the same change:
- Add an explicit clause for
{"kill", "StateTooLargeError"} in step_icon/1, mapping to the same icon as OOMError (hero-exclamation-circle, yellow), since both are resource-budget kills. The textual label next to the icon already shows the precise error_type, so the user can still tell the two apart.
- Add a
{"kill", _} catch-all that falls back to the same icon, so any future worker exit type degrades gracefully instead of crashing the LiveView. The error_type field is a free-form string set by the worker and Lightning has no enum constraining it, so this class of crash will keep recurring otherwise.
Mirror both changes in the React StepIcon so the collaborative editor renders consistently with the runs UI.
What's broken
When a step finishes with
exit_reason = "kill"anderror_type = "StateTooLargeError", the runs UI crashes with aCaseClauseErrorwhile rendering the step icon. The project history page and the run detail page both fail on render whenever they include such a step. Workflow execution itself is unaffected. Only the rendering breaks.The crash is in
LightningWeb.RunLive.Components.step_icon/1, which has explicit clauses forSecurityError,ImportError,TimeoutError, andOOMError, but no clause forStateTooLargeErrorand no catch-all.The same mapping is mirrored in the React
StepIconused by the collaborative editor (assets/js/collaborative-editor/components/run-viewer/StepIcon.tsx). It has a gray ellipsis fallback so it doesn't crash, but it renders the killed step as "pending", which is misleading.How it surfaced
Sentry on
v2.16.2, both alerts from a single project that hit the newStateTooLargeErrorexit type from the worker:What to fix
Two things, in the same change:
{"kill", "StateTooLargeError"}instep_icon/1, mapping to the same icon asOOMError(hero-exclamation-circle, yellow), since both are resource-budget kills. The textual label next to the icon already shows the preciseerror_type, so the user can still tell the two apart.{"kill", _}catch-all that falls back to the same icon, so any future worker exit type degrades gracefully instead of crashing the LiveView. Theerror_typefield is a free-form string set by the worker and Lightning has no enum constraining it, so this class of crash will keep recurring otherwise.Mirror both changes in the React
StepIconso the collaborative editor renders consistently with the runs UI.