@maxdml a question just so I understand how you're expecting the user experience to change with this feature.

Option 1: User experience stays the same but runAsStep internally runs the func inside a Go routine:

 func Workflow(dbosCtx dbos.DBOSContext, scheduledTime time.Time) (Any, error) {
	res1, err := dbos.RunAsStep(dbosCtx, func(ctx context.Context) (Any, error) {
		return func(ctx)
	})

	if err != nil {
		return Any{}, err
	}

	res2, err := dbos.RunAsStep(dbosCtx, func(ctx context.Context) (Any, error) {
		return func2(ctx, Any)
	})

	if err != nil {
		return Any, err
	}

	return Any, nil
}

Option 2: User experiences changes to enable users to run the step function from a Go routine within the workflow:

The following code is just for illustration the syntax and implementation will be different:

 func Workflow(dbosCtx dbos.DBOSContext, scheduledTime time.Time) (Any, error) {
      
         var wg sync.WaitGroup
           
       // the stepId generation would be done side RunAsStep and then the step func is inside a Go routine
       // we will allow RunAsStep to take in a a func with a go routine signature

       res1, err := dbos.RunAsStep(dbosCtx, func(ctx context.Context) (Any, error) {
		return durableGo(&wg)
	})

       wg.Wait()

	if err != nil {
		return Any{}, err
	}

	return Any, nil
}

Which option did you have mind?

Support calling runAsStep in goroutines inside workflows #90

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions