safe message passing sample

[Quinn-With-Two-Ns]

Add safe message passing sample.

Code based on https://github.com/temporalio/samples-python/tree/main/message_passing/safe_message_handlers

[dandavison]

Nice, all looks good, except I have a concern that we're doing start/stop wrong in all our samples (except Go?).

[dandavison]

Can you educate me on why we convert the one exception into the other?

[dandavison]

These are mutually exclusive -- can we use an enum for them? (Also as booleans would it be more idiomatic in java for them to start with is or does that only apply to methods?)

[dandavison]

So if someone sends the stop signal by mistake, it will just hang, and then the next time they start the cluster it will suddenly stop. That seems undesirable. That suggests this should be an update, so we can return success/fail.

(It's the same in the other non-Go languages)

[dandavison]

I think we need to check that the cluster's in an appropriate state to proceed to the next lines. That suggests this should be an update, so we can return success/fail.

(If so it's a bug in the other non-Go languages)

[dandavison]

Suggested change

	// exception from there, or raise an ApplicationFailure. Other exceptions in the main
	// handler
	// will cause the workflow to keep retrying and get it stuck.
	// exception from there, or raise an ApplicationFailure. Other exceptions in the main
	// handler will cause the workflow to keep retrying and get it stuck.

[dandavison]

Suggested change

	// This call would be dangerous without nodesLock because it yields control and allows
	// interleaving
	// with assignNodesToJob and performHealthChecks, which all touch this.state.nodes.
	// This call would be dangerous without nodesLock because it yields control and allows
	// interleaving with assignNodesToJob and performHealthChecks, which all touch this.state.nodes.

[dandavison]

Suggested change

	// The cluster manager is a long-running "entity" workflow so we need to periodically checkpoint
	// its state and
	// continue-as-new.
	// The cluster manager is a long-running "entity" workflow so we need to periodically checkpoint
	// its state and continue-as-new.

[dandavison]

Haha I don't get your IDE's word-wrapping decisions! I've left a bunch of changes like these.

Suggested change

	// In workflows that continue-as-new, it's convenient to store all your state in one serializable
	// structure
	// to make it easier to pass between runs
	// In workflows that continue-as-new, it's convenient to store all your state in one serializable
	// structure to make it easier to pass between runs

[dandavison]

Suggested change

	// This is an update as opposed to a signal because the client may want to wait for nodes to be
	// allocated
	// before sending work to those nodes.
	// Returns the list of node names that were allocated to the job.
	// This is an update as opposed to a signal because the client may want to wait for nodes to be
	// allocated before sending work to those nodes.
	// Returns the list of node names that were allocated to the job.

[dandavison]

Suggested change

	// Even though it returns nothing, this is an update because the client may want to track it, for
	// example
	// to wait for nodes to be unassigned before reassigning them.
	// Even though it returns nothing, this is an update because the client may want to track it, for
	// example to wait for nodes to be unassigned before reassigning them.