Fix some documentation (#976)

internal/schedule_client.go

@@ -591,6 +591,8 @@ type (
 		Create(ctx context.Context, options ScheduleOptions) (ScheduleHandle, error)
 
 		// List returns an interator to list all schedules
+		//
+		// Note: When using advanced visibility List is eventually consistent.
 		List(ctx context.Context, options ScheduleListOptions) (ScheduleListIterator, error)
 
 		// GetHandle returns a handle to a Schedule

internal/workflow.go

@@ -1018,8 +1018,6 @@ func (wc *workflowEnvironmentInterceptor) Now(ctx Context) time.Time {
 // this NewTimer() to get the timer instead of the Go lang library one(timer.NewTimer()). You can cancel the pending
 // timer by cancel the Context (using context from workflow.WithCancel(ctx)) and that will cancel the timer. After timer
 // is canceled, the returned Future become ready, and Future.Get() will return *CanceledError.
-// The current timer resolution implementation is in seconds and uses math.Ceil(d.Seconds()) as the duration. But is
-// subjected to change in the future.
 func NewTimer(ctx Context, d time.Duration) Future {
 	i := getWorkflowOutboundInterceptor(ctx)
 	return i.NewTimer(ctx, d)
@@ -1063,8 +1061,6 @@ func (wc *workflowEnvironmentInterceptor) NewTimer(ctx Context, d time.Duration)
 // Sleep() returns nil if the duration d is passed, or it returns *CanceledError if the ctx is canceled. There are 2
 // reasons the ctx could be canceled: 1) your workflow code cancel the ctx (with workflow.WithCancel(ctx));
 // 2) your workflow itself is canceled by external request.
-// The current timer resolution implementation is in seconds and uses math.Ceil(d.Seconds()) as the duration. But is
-// subjected to change in the future.
 func Sleep(ctx Context, d time.Duration) (err error) {
 	i := getWorkflowOutboundInterceptor(ctx)
 	return i.Sleep(ctx, d)

workflow/deterministic_wrappers.go

@@ -160,8 +160,6 @@ func Now(ctx Context) time.Time {
 // this NewTimer() to get the timer instead of the Go lang library one(timer.NewTimer()). You can cancel the pending
 // timer by cancel the Context (using context from workflow.WithCancel(ctx)) and that will cancel the timer. After timer
 // is canceled, the returned Future become ready, and Future.Get() will return *CanceledError.
-// The current timer resolution implementation is in seconds and uses math.Ceil(d.Seconds()) as the duration. But is
-// subjected to change in the future.
 func NewTimer(ctx Context, d time.Duration) Future {
 	return internal.NewTimer(ctx, d)
 }
@@ -172,8 +170,6 @@ func NewTimer(ctx Context, d time.Duration) Future {
 // Sleep() returns nil if the duration d is passed, or it returns *CanceledError if the ctx is canceled. There are 2
 // reasons the ctx could be canceled: 1) your workflow code cancel the ctx (with workflow.WithCancel(ctx));
 // 2) your workflow itself is canceled by external request.
-// The current timer resolution implementation is in seconds and uses math.Ceil(d.Seconds()) as the duration. But is
-// subjected to change in the future.
 func Sleep(ctx Context, d time.Duration) (err error) {
 	return internal.Sleep(ctx, d)
 }

workflow/doc.go

@@ -36,7 +36,7 @@ In order to facilitate this operational model both the Temporal programming fram
 some requirements and restrictions on the implementation of the coordination logic. The details of these requirements
 and restrictions are described in the "Implementation" section below.
 
-Overview
+# Overview
 
 The sample code below shows a simple implementation of a workflow that executes one activity. The workflow also passes
 the sole parameter it receives as part of its initialization as a parameter to the activity.
@@ -71,7 +71,7 @@ the sole parameter it receives as part of its initialization as a parameter to t
 
 The following sections describe what is going on in the above code.
 
-Declaration
+# Declaration
 
 In the Temporal programing model a workflow is implemented with a function. The function declaration specifies the
 parameters the workflow accepts as well as any values it might return.
@@ -91,7 +91,7 @@ essentially means that params can’t be channels, functions, variadic, or unsaf
 Since it only declares error as the return value it means that the workflow does not return a value. The error return
 value is used to indicate an error was encountered during execution and the workflow should be failed.
 
-Implementation
+# Implementation
 
 In order to support the synchronous and sequential programming model for the workflow implementation there are certain
 restrictions and requirements on how the workflow implementation must behave in order to guarantee correctness. The
@@ -119,7 +119,7 @@ A simplistic way to think about these requirements is that the workflow code:
 
 Now that we laid out the ground rules we can take a look at how to implement some common patterns inside workflows.
 
-Special Temporal client library functions and types
+# Special Temporal client library functions and types
 
 The Temporal client library provides a number of functions and types as alternatives to some native Go functions and
 types. Usage of these replacement functions/types is necessary in order to ensure that the workflow code execution is
@@ -137,12 +137,12 @@ Time related functions:
   - workflow.Now() : This is a replacement for time.Now()
   - workflow.Sleep() : This is a replacement for time.Sleep()
 
-Failing a Workflow
+# Failing a Workflow
 
 To mark a workflow as failed all that needs to happen is for the workflow function to return an error via the err
 return value.
 
-Execute Activity
+# Execute Activity
 
 The primary responsibility of the workflow implementation is to schedule activities for execution. The most
 straightforward way to do that is via the library method workflow.ExecuteActivity:
@@ -213,7 +213,7 @@ Get() methods of the future at a later time.
 To implement more complex wait conditions on the returned future objects, use the workflow.Selector class. Take a look
 at our Pickfirst sample for an example of how to use of workflow.Selector.
 
-Child Workflow
+# Child Workflow
 
 workflow.ExecuteChildWorkflow enables the scheduling of other workflows from within a workflow's implementation. The
 parent workflow has the ability to "monitor" and impact the life-cycle of the child workflow in a similar way it can do
@@ -280,15 +280,15 @@ pattern, extra care needs to be taken to ensure the child workflow is started be
 		return err
 	}
 
-Error Handling
+# Error Handling
 
 Activities and child workflows can fail. Activity errors are *temporal.ActivityError and errors during child workflow
 execution are *temporal.ChildWorkflowExecutionError. The cause of the errors may be types like
 *temporal.ApplicationError, *temporal.TimeoutError, *temporal.CanceledError, and *temporal.PanicError.
 
 See ExecuteActivity() and ExecuteChildWorkflow() for details.
 
-Signals
+# Signals
 
 Signals provide a mechanism to send data directly to a running workflow. Previously, you had two options for passing
 data to the workflow implementation:
@@ -325,7 +325,7 @@ workflow also has the option to stop execution by blocking on a signal channel.
 In the example above, the workflow code uses workflow.GetSignalChannel to open a workflow.Channel for the named signal.
 We then use a workflow.Selector to wait on this channel and process the payload received with the signal.
 
-ContinueAsNew Workflow Completion
+# ContinueAsNew Workflow Completion
 
 Workflows that need to rerun periodically could naively be implemented as a big for loop with a sleep where the entire
 logic of the workflow is inside the body of the for loop. The problem with this approach is that the history for that
@@ -343,7 +343,7 @@ workflow function should terminate by returning the special ContinueAsNewError e
 
 For a complete example implementing this pattern please refer to the Cron example.
 
-SideEffect API
+# SideEffect API
 
 workflow.SideEffect executes the provided function once, records its result into the workflow history, and doesn't
 re-execute upon replay. Instead, it returns the recorded result. Use it only for short, nondeterministic code snippets,
@@ -368,7 +368,7 @@ SideEffect function any other way than through its recorded return value.
 		....
 	}
 
-Query API
+# Query API
 
 A workflow execution could be stuck at some state for longer than expected period. Temporal provide facilities to query
 the current call stack of a workflow execution. You can use tctl to do the query, for example:
@@ -413,7 +413,7 @@ cli:
 
 Besides using tctl, you can also issue query from code using QueryWorkflow() API on temporal Client object.
 
-Registration
+# Registration
 
 For some client code to be able to invoke a workflow type, the worker process needs to be aware of all the
 implementations it has access to. A workflow is registered with the following call:
@@ -430,7 +430,7 @@ Similarly, we need to have at least one worker that hosts the activity functions
 
 See the activity package for more details on activity registration.
 
-Testing
+# Testing
 
 The Temporal client library provides a test framework to facilitate testing workflow implementations. The framework is
 suited for implementing unit tests as well as functional tests of the workflow logic.
@@ -498,7 +498,7 @@ The code below implements the unit tests for the SimpleWorkflow sample.
 		suite.Run(t, new(UnitTestSuite))
 	}
 
-Setup
+# Setup
 
 First, we define a "test suite" struct that absorbs both the basic suite functionality from testify
 http://godoc.org/github.com/stretchr/testify/suite via suite.Suite and the suite functionality from the Temporal test
@@ -512,7 +512,7 @@ indeed called by invoking s.env.AssertExpectations(s.T()).
 
 Finally, we create a regular test function recognized by "go test" and pass the struct to suite.Run.
 
-A Simple Test
+# A Simple Test
 
 The simplest test case we can write is to have the test environment execute the workflow and then evaluate the results.
 
@@ -534,7 +534,7 @@ to s.env.IsWorkflowComplete(). We also assert that no errors where returned by a
 s.env.GetWorkflowError(). If our workflow returned a value, we we can retrieve that value via a call to
 s.env.GetWorkflowResult(&value) and add asserts on that value.
 
-Activity Mocking and Overriding
+# Activity Mocking and Overriding
 
 When testing workflows, especially unit testing workflows, we want to test the workflow logic in isolation.
 Additionally, we want to inject activity errors during our tests runs. The test framework provides two mechanisms that
@@ -588,5 +588,8 @@ original activity function.
 
 Since this can be an entire function, there really is no limitation as to what we can do in here. In this example, to
 assert that the "value" param has the same content to the value param we passed to the workflow.
+
+NOTE: The default MaximumAttempts for retry policy set by server is 0 which means unlimited retries.
+However, during a unit test the default MaximumAttempts is 10 to avoid a test getting stuck.
 */
 package workflow