Skip to content
This repository has been archived by the owner on Oct 9, 2023. It is now read-only.

BugFix: SubWorkflow and dynamic node handling failure #84

Merged
merged 8 commits into from
Mar 13, 2020
Merged

Conversation

kumare3
Copy link
Contributor

@kumare3 kumare3 commented Mar 12, 2020

TL;DR

Please replace this text with a description of what this PR accomplishes.

Type

  • Bug Fix
  • Feature
  • Plugin

Are all requirements met?

  • Code completed
  • Smoke tested
  • Unit tests added
  • Code documentation added
  • Any pending items have an associated Issue

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

@codecov-io
Copy link

codecov-io commented Mar 12, 2020

Codecov Report

Merging #84 into master will increase coverage by 0.13%.
The diff coverage is 60%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
pkg/controller/config/config.go 0% <ø> (ø) ⬆️
pkg/controller/nodes/executor.go 58.64% <100%> (+0.23%) ⬆️
pkg/controller/nodes/dynamic/handler.go 62.39% <50%> (ø) ⬆️
pkg/controller/nodes/subworkflow/util.go

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bc96237...44a7a94. Read the comment docs.

return nil
}
logger.Info(ctx, "Finalizing Subworkflow")
wf := nCtx.Workflow()
Copy link
Contributor

Choose a reason for hiding this comment

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

this is deprecated?

Copy link
Contributor Author

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)
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

contextual parent

Ketan Umare added 3 commits March 12, 2020 00:20
 Increment was called before calling the abort. Since the logic is
derived using the current attempt number, everything broke
EngHabu
EngHabu previously approved these changes Mar 12, 2020
@@ -374,6 +374,7 @@ func (c *nodeExecutor) handleNode(ctx context.Context, w v1alpha1.ExecutableWork
return executors.NodeStatusUndefined, err
}

nodeStatus.IncrementAttempts()
Copy link
Contributor

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?

Copy link
Contributor Author

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()))
Copy link
Contributor

Choose a reason for hiding this comment

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

delete?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

wild-endeavor
wild-endeavor previously approved these changes Mar 12, 2020
EngHabu
EngHabu previously approved these changes Mar 12, 2020
@kumare3 kumare3 merged commit 34c7598 into master Mar 13, 2020
eapolinario pushed a commit to eapolinario/flytepropeller that referenced this pull request Aug 9, 2023
* 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants