💥 Carry over search attributes on continue-as-new if none are explicitly set

[Quinn-With-Two-Ns]

Carry over search attributes on continue-as-new if none are explicitly set, this is the documented behaviour but previously the Java SDK was not actually carrying over search attributes.

closes #2178

---

Note

Carry over existing search attributes across continue-as-new and update test server and tests to support and verify it.

• SDK (workflow execution):
  • SyncWorkflowContext.continueAsNew(...): if no searchAttributes/typedSearchAttributes provided, carry over existing SearchAttributes from replayContext.
  • Copy RetryPolicy from replayContext when ContinueAsNewOptions is null.
• Test Server:
  • StateMachines: include searchAttributes in WorkflowExecutionContinuedAsNewEventAttributes when present.
  • TestWorkflowService.continueAsNew(...): forward continued run searchAttributes into StartWorkflowExecutionRequest.
• Tests:
  • ContinueAsNewTest: add typed search attributes to initial options; assert they are carried over on first continue-as-new and can be overridden on subsequent runs.
• Docs:
  • Minor Javadoc grammar tweak in ContinueAsNewOptions.

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

[cretz]

Technically this is a change to behavior incompatibly if people have built expectation on the carryover not occurring. Should we add a 💥 in the title and note it in release notes? I assume if they want to go back to today's behavior they can provide an explicit empty attr collection?

(not reviewing the PR itself, just confirming the relaying of compatibility change)

[Quinn-With-Two-Ns]

So according to the Javadoc the behaviour has always been to copy if none are specify, the SDK just hasn't been. This is a change in behavior so I have no issue calling it out with 💥 .

And yes if a user wants the previous behaviour they can set an empt collection.