uber-go / cadence-client Goto Github PK

In a lot of cases workflow changes do not affect activity invocations much. In this case the workflow code upgrade could use existing history not for replay but as a "cache" of activity results. This way after upgrade the workflow executes from the beginning, but uses activity results for immediate activity execution.

Consider moving all static type registration as UberFx DI framework.

the clock (with auto forwarding) is not working for some corner cases with child workflow.

=== RUN TestWorkflowTask_NondeterministicDetection
2017-05-16T17:10:59.322Z DEBUG _obj_test/internal_task_handlers.go:299 Processing new workflow task. {"WorkflowType": "testWorkflow", "WorkflowID": "fake-workflow-id", "RunID": "fake-run-id", "PreviousStartedEventId": 2}
2017-05-16T17:10:59.323Z ERROR _obj_test/internal_task_handlers.go:391 Replay and history mismatch. {"error": "nondeterministic workflow: history event is ActivityTaskScheduled: (ActivityId:0, ActivityType:(Name:some_random_activity), TaskList:(Name:taskList), Input:[len=0]), replay decision is ScheduleActivityTask: (ActivityId:0, ActivityType:(Name:Greeter_Activity), TaskList:(Name:taskList), Input:[len=0], ScheduleToCloseTimeoutSeconds:0, ScheduleToStartTimeoutSeconds:0, StartToCloseTimeoutSeconds:0, HeartbeatTimeoutSeconds:0)"}
github.com/uber-go/cadence-client/vendor/go.uber.org/zap.Stack
/home/travis/gopath/src/github.com/uber-go/cadence-client/vendor/go.uber.org/zap/field.go:209
github.com/uber-go/cadence-client/vendor/go.uber.org/zap.(*Logger).check
/home/travis/gopath/src/github.com/uber-go/cadence-client/vendor/go.uber.org/zap/logger.go:273
github.com/uber-go/cadence-client/vendor/go.uber.org/zap.(*Logger).Error
/home/travis/gopath/src/github.com/uber-go/cadence-client/vendor/go.uber.org/zap/logger.go:176
github.com/uber-go/cadence-client/client/cadence.(*workflowTaskHandlerImpl).ProcessWorkflowTask
github.com/uber-go/cadence-client/client/cadence/_test/_obj_test/internal_task_handlers.go:391
github.com/uber-go/cadence-client/client/cadence.(*TaskHandlersTestSuite).TestWorkflowTask_NondeterministicDetection
/home/travis/gopath/src/github.com/uber-go/cadence-client/client/cadence/internal_task_handlers_test.go:189
runtime.call32
/home/travis/.gimme/versions/go1.8.linux.amd64/src/runtime/asm_amd64.s:514
reflect.Value.call
/home/travis/.gimme/versions/go1.8.linux.amd64/src/reflect/value.go:434
reflect.Value.Call
/home/travis/.gimme/versions/go1.8.linux.amd64/src/reflect/value.go:302
github.com/uber-go/cadence-client/vendor/github.com/stretchr/testify/suite.Run.func2
/home/travis/gopath/src/github.com/uber-go/cadence-client/vendor/github.com/stretchr/testify/suite/suite.go:101
testing.tRunner
/home/travis/.gimme/versions/go1.8.linux.amd64/src/testing/testing.go:657

• Instead of workflow fail we want the decision to timeout, so we can upgrade back and make the workflow work.
• Appropriate error messages instead of random exceptions.

This change #117 needs to be reverted and the change should go to the panic handler for dispatcher.

Today, cadence cannot support use-cases where intermediary steps can generate large amounts of data as results. The scaling limitation for this is the size of the history. One idea would be for the client to upload the intermediate results in an object store (ex-S3) and just use the url in the history. This task is to track support for this feature.

if activity's result type is a pointer, when it returns nil, then the result encoding will panic.
Example:
type myData struct{}
func testActivity(ctx context.Context) (*myData, error) {
return nil, errors.New("test-error")
}
when the encoding framework try to encode the nil pointer, it will panic.

We need a metrics collection facility that does not emit duplicate and incorrect metrics when decider code is replayed.

We need a logging facility that can handle the fact that decider code gets replayed without generated unwanted duplicate log lines.

• The two timeouts on the start workflow options needs to be moved to time.duration.

The much needed changes for testify mock has been merged (with slightly changes). We should remove our copy of testify mock and use the official version, with slightly change (panic handler) to the mock calls on our call sites.

When there is error happen in activity and it returns error, that error will be wrapped as ErrorWithDetails and pass to user's decider code. When user get this ErrorWithDetails, they don't know what type the error details is. Today, they could rely on the Reason which is a string, and compare that string to decide what type of error it is. However, the string could have collision, potentially.

We need to decide if current solution (rely on string matching) is fine, or we want to have something more complicated, for example adding error code to the error.

• Add missing metrics
• Remove un-necessary metrics

We need a sleep API that would sleep on real clock in normal case, but sleep on mock clock in unit test environment, something like:
cadence.ActivitySleep(ctx context.Context, d time.Duration)
then, in activity code, instead of:
time.Sleep(d)
it should do:
cadence.ActivitySleep(ctx, d)
this way, ActivitySleep would sleep on real clock in normal case, but sleep on mock clock on unit tests.

• Worker to automatically auto heartbeat.
• Option to opt out.
• Optimization on automation to aggregate heartbeats in a window if activity does it more frequently to decrease load to server.

• Add missing log messages
• Remove un-needed log messages
• Implement a facility to hide "low level" logs unless explicitly enabled

We need to expose the metrics collector registered with worker inside the activities function.

when user mock an activity, we need a way for user to say that the mocked activity would sleep/delay a certain amount of time on workflow clock.
The code would looks something like:
env := testSuite.NewTestWorkflowEnvironment()
env.OnActivity(myActivity, mock.Anything).After(time.Hour).return(mockValues...)

For the above code to work, it needs our PR to testify get merged. If not, then the code would looks like:
waitCh := env.After(time.Hour)
env.OnActivity(myActivity, mock.Anything).WaitUntil(waitCh).return(mockValues...)

Looks like a lot of constants are copied over from server repo and does not makes sense for client. We need to cleanup this file to make sure it only has counter relevant for client.
https://github.com/uber-go/cadence-client/blob/master/common/metrics/constants.go

Pagination of histories could take long time and make sense to decouple pollers from execution of decision logic.

• If the parent workflow is cancelled then all the contexts created out of them remains cancelled. We need a ability to create a context for an activity that doesn't get affected by the parent context cancellation.

Uberfx has this new DIG framework, this task is if we can use to integrate with that framework. We also need to spend some time to understand what this is going to help us before we integrate.

https://github.com/uber-go/dig

Pagination of histories could take long time and make sense to decouple pollers from execution of decision logic.

Make logger registered with worker service available in the activities method.

Have samples for all client features.

Client does not seem to update metrics properly except the workflow started counter

we could use Go's internal package support to move internal code into separate internal package so it is more clear to users on public APIs.

Complete unit-tests for samples