Skip to content

Conversation

shijiesheng
Copy link
Member

@shijiesheng shijiesheng commented May 21, 2025

Detailed Description

  • GetSpanContext API is used for fetch span context from workflow if it exists
  • WithSpanContext() API is used for overriding the existing span context in the workflow so it could be passed to activities and child workflows

Impact Analysis

  • Backward Compatibility: Yes, they are new APIs
  • Forward Compatibility: Yes, WithSpanContext would write the existing span context field and it's readable for old client versions

Testing Plan

  • Unit Tests: No
  • Persistence Tests: No
  • Integration Tests: Yes
  • Compatibility Tests: No

Rollout Plan

  • What is the rollout plan? new release
  • Does the order of deployment matter? no
  • Is it safe to rollback? Does the order of rollback matter? Safe
  • Is there a kill switch to mitigate the impact immediately? Rollback to previous version and remove usages of the new APIs

Why?

Users can now access baggage items in the workflow code.

}

func spanFromContext(ctx Context) opentracing.SpanContext {
func GetSpanContext(ctx Context) opentracing.SpanContext {
Copy link
Member

Choose a reason for hiding this comment

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

should we also expose contextWithSpan or is there another way for users to add their existing context?

Copy link
Member Author

Choose a reason for hiding this comment

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

Now I'm a bit concerned about the determinism if users start a new span inside the workflow.

Copy link
Member

Choose a reason for hiding this comment

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

I guess we don't have a clear story around replay traces. It wouldn't cause non-determinism though. Just weird/duplicate traces potentially.
Are you suggesting to expose the span via GetSpanContext but don't let user set/override the span in the context?

Copy link
Member Author

Choose a reason for hiding this comment

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

You are right. It's still deterministics. Replay is going to cause issues. We will see multiple child spans if we allow users to set them.

Copy link
Member Author

Choose a reason for hiding this comment

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

Using Sideeffect would work. But is span serializable or recoverable?

Copy link
Member

Choose a reason for hiding this comment

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

Not sure. We can try and see. It sounds like we need to start a new span even for replays but let's discuss that separately.

Copy link
Member Author

Choose a reason for hiding this comment

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

SpanContext is serializable and should be passed. With that said, we'll require users to start a short-lived new span just to modify spancontext. Please refer the examples in the comments

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added an integration test which works.

@shijiesheng shijiesheng changed the title Add Workflow.GetSpanContext API Add workflow.GetSpanContext and workflow.WithSpanContext API May 21, 2025
@shijiesheng shijiesheng merged commit 50be4b8 into cadence-workflow:master May 22, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants