Add Workflow.newWorkflowQueue method and ZWorkflowQueue wrapper

[grouzen]

Changes being made

Add ZWorkflow.newWorkflowQueue method and ZWorkflowQueue wrapper for WorkflowQueue

Additional context

/addresses #88

[grouzen]

Is it fine for you to keep all these 3 wrappers in the same file? I'll be happy to move them into separate files if you want.

[vitaliihonta]

Now, looking at the wrapper, I wonder if adding it is worth it. Do you see any possible Scala-specific extensions we can provide? I mean additional methods, supporting Scala-specific types (besides zio.Duration), etc.

Currently, this wrapper brings proper (in)variance checks and a .map method overload for Scala lambdas. What else can we do? Depending on the answer, we'd decide on what to do with those interfaces/wrappers.

[grouzen]

That's a good question. I think, it is also worth adding it because of additional null checks for some methods that return null. Also, some methods throw exceptions, and that's the question I was going to ask you. Is allowing methods to raise exceptions in a workflow code semantically correct? I mean, I think usually you want to have control over such dangerous behavior, and wrapping such methods in Try sounds good to me.

[vitaliihonta]

Unfortunately, the workflow code should be built without Try, Either, or any other container. Temporal's error-handling logic can only work with Exceptions. If we wrap an error into Try, Temporal won't retry the workflow unless you get. Therefore, the existing zio-temporal functionality related to the Workflow code (such as activity invocations) doesn't wrap error-prune code but raises an exception

[grouzen]

Okay, got it. So, deciding whether we should have a wrapper is up to you. I don't see any other benefits besides what we already mentioned.

[vitaliihonta]

It sounds enough to me. We can add more methods later 😃

[vitaliihonta]

Minor: can it be an interface as well? The ZWorkflowQueue can implement two interfaces

[grouzen]

Unfortunately, it should be a class because the original QueueConsumer.map returns QueueConsumer, which is a supertype for WorkflowQueue. That means we can't implement map method like:

def map[R](f: E => R): ZWorkflowQueue[R] =
    new ZWorkflowQueue(toJava.map(e => f(e)) // compiler error, toJava.map returns QueueConsumer but ZWorkflowQueue receives WorkflowQueue

Hope it makes sense.

[vitaliihonta]

Okay, that's strange, but we should follow it 😄

[vitaliihonta]

@grouzen, if there is any Javadoc for the Java Queue, could you copy it into our wrapper as well?
Otherwise LGTM! The only thing nice to have is usage examples. I haven't found them yet in Java SDK samples 🤔

[grouzen]

@grouzen, if there is any Javadoc for the Java Queue, could you copy it into our wrapper as well? Otherwise LGTM! The only thing nice to have is usage examples. I haven't found them yet in Java SDK samples 🤔

Sure, I'll copy the docs for the methods.
That was my main struggle - no examples and docs about WorkflowQueue. I've managed to find some info on the community forum. I'll add maybe some test cases along with examples.

[codecov-commenter]

Codecov Report

Merging #127 (c3c7f4b) into main (669309f) will decrease coverage by 1.38%.
Report is 3 commits behind head on main.
The diff coverage is 7.69%.

@@            Coverage Diff             @@
##             main     #127      +/-   ##
==========================================
- Coverage   38.56%   37.19%   -1.38%     
==========================================
  Files         115      127      +12     
  Lines        4055     4850     +795     
==========================================
+ Hits         1564     1804     +240     
- Misses       2491     3046     +555     

Files	Coverage Δ
...c/main/scala/zio/temporal/workflow/ZWorkflow.scala	39.26% <100.00%> (-3.24%)	⬇️
...n/scala/zio/temporal/workflow/ZWorkflowQueue.scala	0.00% <0.00%> (ø)

... and 39 files with indirect coverage changes

[vitaliihonta]

@grouzen I'm going to merge it into the new release. Feel free to add tests and examples in a new PR!