[GOBBLIN-2259] Coerce $UNKNOWN ExecutionStatus to PENDING in FlowExec…#4187
Open
DaisyModi wants to merge 1 commit intoapache:masterfrom
Open
[GOBBLIN-2259] Coerce $UNKNOWN ExecutionStatus to PENDING in FlowExec…#4187DaisyModi wants to merge 1 commit intoapache:masterfrom
DaisyModi wants to merge 1 commit intoapache:masterfrom
Conversation
DaisyModi
force-pushed
the
GOBBLIN-2259-unknown-executionstatus-500
branch
3 times, most recently
from
d250e65 to
1ffcb20
Compare
| if (flowExecutionStatus == ExecutionStatus.$UNKNOWN) { | ||
| log.warn("FlowExecution {}/{}/{} has $UNKNOWN flow status; coercing to PENDING. Check state store for data quality issue.", | ||
| flowId.getFlowGroup(), flowId.getFlowName(), monitoringFlowStatus.getFlowExecutionId()); | ||
| flowExecutionStatus = ExecutionStatus.PENDING; |
Contributor
There was a problem hiding this comment.
Why PENDING over RUNNING as the coercion target? RUNNING might be a closer semantic match than PENDING, since the flow is clearly active enough for executions to appear in the collection response.
| } | ||
|
|
||
| @Test | ||
| public void testConvertFlowStatusPreservesValidStatus() { |
Contributor
There was a problem hiding this comment.
Can we add a terminal-status test case to testConvertFlowStatusPreservesValidStatus?
…utionResource ExecutionStatus.$UNKNOWN is a Pegasus in-memory sentinel, not a symbol declared in ExecutionStatus.pdl. When it reaches the response, Rest.li rejects it during serialization and returns HTTP 500 for the entire collection — a single poisoned record takes down every execution in the same latestFlowExecution batch. This can happen when no flow-level (NA/NA) status event was persisted for an execution, e.g., because ReevaluateDagProc early-returned without emitting the flow-level event while a concurrent DagProc cleaned up the Dag. The result is a "zombie" execution: job-level terminal rows exist in the state store, but no NA row, so JobStatusRetriever.getFlowStatusFromJobStatuses returns its $UNKNOWN default. Guard at the REST boundary: coerce $UNKNOWN to PENDING before building the FlowExecution response, and log a WARN so the underlying data-quality issue stays observable. PENDING is the least-misleading valid enum value for "flow exists but terminal state unknown" — polling clients continue polling, so we never falsely report a terminal status we cannot verify. Added tests: - testConvertFlowStatusCoercesUnknownToPending - testConvertFlowStatusPreservesValidStatus
DaisyModi
force-pushed
the
GOBBLIN-2259-unknown-executionstatus-500
branch
from
1ffcb20 to
4a55a67
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…utionResource
ExecutionStatus.$UNKNOWN is a Pegasus in-memory sentinel, not a symbol declared in ExecutionStatus.pdl. When it reaches the response, Rest.li rejects it during serialization and returns HTTP 500 for the entire collection - a single poisoned record takes down every execution in the same latestFlowExecution batch.
Guard at the REST boundary: coerce $UNKNOWN to PENDING before building the FlowExecution response, and log a WARN so the underlying data-quality issue (missing flow-level status event or schema skew) stays observable.
Added tests:
Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA
Description
Tests
Commits