-
Notifications
You must be signed in to change notification settings - Fork 59
BugFix: SubWorkflow and dynamic node handling failure #84
Conversation
Codecov Report
@@ Coverage Diff @@
## master #84 +/- ##
==========================================
+ Coverage 49.48% 49.62% +0.13%
==========================================
Files 127 123 -4
Lines 7881 7599 -282
==========================================
- Hits 3900 3771 -129
+ Misses 3598 3460 -138
+ Partials 383 368 -15
Continue to review full report at Codecov.
|
return nil | ||
} | ||
logger.Info(ctx, "Finalizing Subworkflow") | ||
wf := nCtx.Workflow() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is deprecated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes because I want to move away from using a workflow and move to using just the contextual structure
@@ -174,7 +175,24 @@ func (s *subworkflowHandler) HandleSubWorkflowFailingNode(ctx context.Context, n | |||
return s.DoInFailureHandling(ctx, nCtx, contextualSubWorkflow) | |||
} | |||
|
|||
func (s *subworkflowHandler) HandleAbort(ctx context.Context, nCtx handler.NodeExecutionContext, w v1alpha1.ExecutableWorkflow, workflowID v1alpha1.WorkflowID) error { | |||
func (s *subworkflowHandler) HandleAbort(ctx context.Context, nCtx handler.NodeExecutionContext, w v1alpha1.ExecutableWorkflow, workflowID v1alpha1.WorkflowID, reason string) error { | |||
subWorkflow := w.FindSubWorkflow(workflowID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the w
here is the highest level, parent workflow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
contextual parent
Increment was called before calling the abort. Since the logic is derived using the current attempt number, everything broke
@@ -374,6 +374,7 @@ func (c *nodeExecutor) handleNode(ctx context.Context, w v1alpha1.ExecutableWork | |||
return executors.NodeStatusUndefined, err | |||
} | |||
|
|||
nodeStatus.IncrementAttempts() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add docs for why we should do it here and not after the handle() returns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup
@@ -614,7 +615,7 @@ func TestLaunchPlanHandler_HandleAbort(t *testing.T) { | |||
|
|||
t.Run("abort-success", func(t *testing.T) { | |||
mockLPExec := &mocks.Executor{} | |||
//mockStore := storage.NewCompositeDataStore(storage.URLPathConstructor{}, storage.NewDefaultProtobufStore(utils.FailingRawStore{}, promutils.NewTestScope())) | |||
// mockStore := storage.NewCompositeDataStore(storage.URLPathConstructor{}, storage.NewDefaultProtobufStore(utils.FailingRawStore{}, promutils.NewTestScope())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
delete?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
* Handling Finalize for subworkflows * config change * improved logging * Fixing the regression Increment was called before calling the abort. Since the logic is derived using the current attempt number, everything broke * updated and fixed tests * comment updated * updated * More unit tests
TL;DR
Please replace this text with a description of what this PR accomplishes.
Type
Are all requirements met?
Complete description
How did you fix the bug, make the feature etc. Link to any design docs etc
Tracking Issue
flyteorg/flyte#202
Follow-up issue
NA