-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add documentation for propagators and how they are executed #1312
Conversation
@@ -36,8 +36,25 @@ type HeaderReader interface { | |||
ForEachKey(handler func(string, []byte) error) error | |||
} | |||
|
|||
// ContextPropagator is an interface that determines what information from | |||
// context to pass along | |||
// ContextPropagator determines what information from context to pass along. |
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.
thanks for filling in this documentation gap. @shijiesheng can you review please?
internal/headers.go
Outdated
// ContextPropagator is an interface that determines what information from | ||
// context to pass along | ||
// ContextPropagator determines what information from context to pass along. | ||
// Returning an error from any of its methods will prevent the normal execution |
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 actually not true. At least this Inject method will fail open.
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.
@alshopov Could you update the doc here? Or should we handle it on our side?
Clarify behavior on return of error Document the whole execution sequence Docs added to both internal package and exposed type alias due to: golang/go#44905 Signed-off-by: Alexander Shopov <[email protected]>
@shijiesheng, @3vilhamster: I have updated the docs. I have verified the behaviour via fiddling with: Note that I am documenting current behavior - I am not sure whether it is the intended behavior. I have no idea whether the current silent non-failure on errors from Inject* methods is a good idea - leaving this up to you. Sorry for the delay - free time is a rare premium |
// -> ExtractToWorkflow -> Start executing a workflow -> InjectFromWorkflow -> | ||
// Cadence -> Go Activity Worker -> Extract -> Execute Activity |
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.
nit: this might make it easier for users to understand
// -> ExtractToWorkflow -> Start executing a workflow -> InjectFromWorkflow -> | |
// Cadence -> Go Activity Worker -> Extract -> Execute Activity | |
// -> ExtractToWorkflow -> Start executing a workflow -> Schedule an activity -> InjectFromWorkflow -> | |
// Cadence -> Go Activity Worker -> Extract -> Execute Activity |
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.
I think that it is out of the scope of the context propagator, so we might add it if it causes confusion.
// The whole sequence of execution is: | ||
// | ||
// Process initiating the workflow -> Inject -> Cadence -> Go Workflow Worker | ||
// -> ExtractToWorkflow -> Start executing a workflow -> InjectFromWorkflow -> |
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.
ditto
Codecov Report
Additional details and impacted files
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
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.
LGTM
Clarify behavior on return of error
Document the whole execution sequence
Docs added to both internal package and exposed type alias due to: golang/go#44905