feature: Add Temporal workflow example for Scala 3

[xerial]

Summary

• Adds uni-temporal-example module with Temporal SDK (1.27.0) to explore workflow orchestration usability in Scala 3
• Implements two example workflows: HelloWorkflow (basic greeting) and DataPipelineWorkflow (multi-step pipeline with retry handling)
• Includes ScalaDataConverter for Jackson/Scala 3 case class serialization interop
• Tests use Temporal's in-process TestWorkflowEnvironment — no external server needed

Key findings so far

• Temporal Java SDK works with Scala 3 traits as workflow/activity interfaces
• Jackson requires jackson-module-scala for case class deserialization
• TestWorkflowEnvironment makes unit testing straightforward
• Workflow/Activity interface separation is enforced but natural in Scala

Test plan

• HelloWorkflowTest — basic greeting workflow (2 tests)
• DataPipelineWorkflowTest — multi-step pipeline with transient failure retry (2 tests)
• Manual testing with temporal server start-dev (via TemporalWorkerApp / TemporalClientApp)

🤖 Generated with Claude Code

[xerial]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new module, uni-temporal-example, to explore Temporal workflow orchestration in Scala 3. It includes implementations for a simple 'Hello World' workflow and a multi-step data pipeline, along with unit tests and a local worker application. Feedback focuses on ensuring that WorkflowClient instances in both the worker and client applications are configured with the custom ScalaDataConverter to correctly serialize Scala 3 case classes. Additionally, it is recommended to use Temporal's ActivityExecutionContext instead of a manual AtomicInteger for tracking activity attempts to ensure robustness across worker instances.

[gemini-code-assist]

The WorkflowClient needs to be configured with ScalaDataConverter to correctly handle Scala 3 case classes (like PipelineInput and PipelineResult). Without this, the worker will fail to deserialize workflow inputs and activity results because the default Jackson converter doesn't support Scala 3 case classes without a no-arg constructor.

  val client  = WorkflowClient.newInstance(
    service,
    io.temporal.client.WorkflowClientOptions.newBuilder().setDataConverter(ScalaDataConverter.converter).build()
  )

[gemini-code-assist]

Similar to the worker, the client application must also use ScalaDataConverter to serialize Scala case classes when starting workflows. Otherwise, the Temporal server will receive incompatible payloads that the worker won't be able to process.

  val client  = WorkflowClient.newInstance(
    service,
    io.temporal.client.WorkflowClientOptions.newBuilder().setDataConverter(ScalaDataConverter.converter).build()
  )

[gemini-code-assist]

Instead of using a manual AtomicInteger to track attempts, it is recommended to use Temporal's ActivityExecutionContext. This is more robust as it works correctly across different worker instances and provides the actual attempt number tracked by the Temporal server, which is useful for implementing custom retry logic or logging.

/**
  * DataActivities implementation with a simulated transient failure on the first fetch attempt.
  *
  * Temporal supplies the attempt number via ActivityExecutionContext, which is the recommended
  * way to track attempts across retries.
  */
class DataActivitiesImpl extends DataActivities with LogSupport:

  override def fetchData(sourceId: String): String =
    // Use Temporal's ActivityExecutionContext to get the current attempt number
    val attempt = io.temporal.activity.Activity.getExecutionContext().getInfo().getAttempt()
    logger.info(s"fetchData attempt ${attempt} for source '${sourceId}'")
    if attempt == 1 then
      // Simulate a transient failure on the first attempt
      throw RuntimeException(s"Transient network error fetching '${sourceId}' (attempt 1)")
    s"raw-data-for-${sourceId}"

[gemini-code-assist]

Code Review

This pull request introduces a new module, uni-temporal-example, to explore Temporal workflow orchestration in Scala 3. It includes a design document, workflow and activity implementations for a data pipeline and a simple greeting service, custom Jackson serialization for Scala case classes, and integration tests. Feedback focuses on improving maintainability by extracting version constants in build.sbt, reducing test boilerplate through fixture methods, and optimizing workflow stub usage in tests.

[gemini-code-assist]

For consistency with TEMPORAL_SDK_VERSION and for better maintainability, please extract the hardcoded versions for jackson-module-scala and slf4j-jdk14 into val constants, defined near the TEMPORAL_SDK_VERSION definition.

[gemini-code-assist]

There is significant boilerplate code duplicated across the two test cases (environment setup, worker registration, stub creation). To improve maintainability and reduce duplication, consider extracting this common setup into a fixture method that uses the loan pattern. This would make the tests cleaner and easier to read.

For example:

private def withWorkflowStub(testCode: DataPipelineWorkflow => Unit): Unit = {
  val testEnv = newTestEnv()
  try {
    val worker = testEnv.newWorker(TemporalExample.TaskQueue)
    worker.registerWorkflowImplementationTypes(classOf[DataPipelineWorkflowImpl])
    worker.registerActivitiesImplementations(new DataActivitiesImpl())
    testEnv.start()

    val stub = testEnv.getWorkflowClient.newWorkflowStub(
      classOf[DataPipelineWorkflow],
      WorkflowOptions.newBuilder().setTaskQueue(TemporalExample.TaskQueue).build()
    )
    testCode(stub)
  } finally {
    testEnv.close()
  }
}

// Then in your test:
test("DataPipelineWorkflow completes after transient fetch failure") {
  withWorkflowStub { stub =>
    val result = stub.process(PipelineInput("sensor-42", "raw,data,stream"))
    // assertions...
  }
}

Note that new DataActivitiesImpl() is used to ensure state is not shared between tests.

[gemini-code-assist]

The workflow stub is being recreated inside the for loop for each iteration. This is unnecessary and inefficient. The stub should be created once before the loop and reused.

      val stub = client.newWorkflowStub(
        classOf[HelloWorkflow],
        WorkflowOptions.newBuilder().setTaskQueue(TemporalExample.TaskQueue).build()
      )
      for name <- Seq("Alice", "Bob", "Temporal") do
        stub.sayHello(name) shouldBe s"Hello, ${name}!"

[gemini-code-assist]

There is significant boilerplate code duplicated across the two test cases (environment setup, worker registration, stub creation). To improve maintainability and reduce duplication, consider extracting this common setup into a fixture method that uses the loan pattern. This would also address the inefficient stub creation in the second test.