Introduce SDK flag to use user DC on Memo's

[yuandrew]

What was changed

Introduced an SDK flag, SDKFlagMemoUserDCEncode, to configure new behavior, where we actually use the user data converter when encoding Memo's. If user DC errors out, the default DC will be used as a fallback. If that also returns an error, the user DC error will be returned to the caller.

SDK flag is still set to false by default, so no behavior changes. After a Go SDK release or two, will the flag then be enabled by default.

Why?

Correct behavior to match other SDKs

Checklist

1. Closes Memo does not go through user provided data coverter #1045

2. How was this tested:
   Added new tests that flip on/off the SDK flag and validates behavior

3. Any docs updates needed?

---

Note

Adds SDKFlagMemoUserDCEncode to optionally encode workflow/schedule memos with the user data converter (falling back to default), and updates codepaths and tests to honor it.

• Flags & config:
  • Introduce SDKFlagMemoUserDCEncode with env toggle MEMO_USER_DC_ENCODE and setter SetMemoUserDCEncode.
• Memo encoding behavior:
  • Add encodeMemoValue and shouldUseMemoUserDataConverter; prefer user DataConverter for memo encoding, fallback to default on error.
  • Extend getWorkflowMemo(..) and validateAndSerializeMemo(..) to accept a memoFlagAccessor and apply flag.
  • Update all call sites (StartWorkflow, SignalWithStart, child workflow start, schedules, testsuite) to pass accessor and/or use new helpers.
• Schedule client:
  • encodeScheduleWorkflowMemo now uses user DC (with fallback) and defaults DC when nil.
• Tests:
  • Add tests validating memo encoding with old/new behavior and failure paths for both workflow and schedule clients.
  • Adjust testsuite memo paths to use new accessor; minor assertions tightened.

^{Written by Cursor Bugbot for commit 049d0fb. This will update automatically on new commits. Configure here.}

[Quinn-With-Two-Ns]

The comment says this is useful for tests, but I don't see this used in the SDK anywhere. Why did we need to add this?

[yuandrew]

It's set and used in SetMemoUserDCEncode(), so we can defer setting it back to its previous flag

[yuandrew]

as well as configuring the default behavior for tests, so we can validate both the old and new behavior

[cretz]

Just for my confirmation (didn't review whole PR or anything), this flag will now be set for any workflow that uses UpsertMemo or ExecuteChildWorkflow but not for any other workflows? But for now this is off by default unless the MEMO_USER_DC_ENCODE env var is set? And I presume one day we'll just turn it on for all users (i.e. change var memoUserDCEncode = os.Getenv("MEMO_USER_DC_ENCODE") != "" to os.Getenv("MEMO_USER_DC_ENCODE") != "false" or something)?

[yuandrew]

this flag will now be set for any workflow that uses UpsertMemo or ExecuteChildWorkflow but not for any other workflows

What do you mean "not for any other workflows"? My understanding is this should be set for all workflows, regardless of if they use UpsertMemo or ExecuteChildWorkflow.

And I presume one day we'll just turn it on for all users (i.e. change var memoUserDCEncode = os.Getenv("MEMO_USER_DC_ENCODE") != "" to os.Getenv("MEMO_USER_DC_ENCODE") != "false" or something)?

Correct, one day we will flip the switch to turn it on by default. iirc server needs a version or 2 to fall back onto, so we want to wait a bit before flipping the switch on a new SDK flag

[cretz]

What do you mean "not for any other workflows"? My understanding is this should be set for all workflows, regardless of if they use UpsertMemo or ExecuteChildWorkflow.

When I looked at when .TryUse(SDKFlagMemoUserDCEncode) was invoked, it was only in those two situations, but I may be misreading

[yuandrew]

ahh no I think you're right, but does it matter if we set the SDK flag if our workflow isn't exercising Memo code? I wanna say no. The flag is primarily for replaying and ensuring this fix doesn't cause NDE with pre-fix histories