[Feature Request] Rust SDK - Queries

[Elvecent]

Is your feature request related to a problem? Please describe.

I'm trying to use this library in Rust and implement Workflows that have some queryable state. However, I can't find a way to make or handle queries, it seems there's something lacking here. Either that or I'm missing something. All I could find was respond_legacy_query, what's that by the way?

Describe the solution you'd like

An API akin to what's there in Go code samples: https://legacy-documentation-sdks.temporal.io/go/how-to-use-queries-in-go https://legacy-documentation-sdks.temporal.io/go/how-to-handle-a-query-in-a-workflow-in-go

[Sushisource]

@Elvecent Indeed, they're not implemented in the Rust SDK itself.

The Rust SDK in this repo exists only for internal testing purposes at this point and comes with no API stability guarantees. As such I probably won't be able to prioritize adding arbitrary query support to it unless I happen to have a reason to need it for testing.

Once we've prioritized releasing a production ready Rust SDK, I plan on changing the API quite a bit, to be trait based, and the main reason I haven't added any real query support yet is because it looks quite funky without a very different API.

If you wanted to contribute something which looks like:

impl WfContext {
    fn register_query(&self, query_name: impl Into<String>, query_fn: impl Fn() -> Payload) {}
}

I'd be open to that as an intermediate solution

[Elvecent]

Thanks for the explanation. It's presently not a pressing need for me, but if that changes, I'll look into it.

[remeq]

@Sushisource is an official Temporal Rust SDK library on a roadmap for future ?

[Sushisource]

@remeq See the blurb at the end of the README here. We do not have official plans to productionize yet.

[awkure]

I was going to implement them myself and have a couple of questions regarding that.

1. How much and what exactly is left for them to be implemented? I've seen there were some developments in https://github.com/temporalio/sdk-core/pull/135 but it appears that they're still unimplemented in WorkflowFuture::handle_job endpoint.
2. I tried doing it with the analogy with signal jobs, but couldn't find where these signals (besides tests) are consumed. It'll be really helpful knowing that.

[awkure]

Ok, the second part was clarified. The first question is still open.

[Elvecent]

It would seem that at least we would need to add

1. A hashmap like sig_chans to WorkflowFuture that would map query names to impl Fn() -> Payload callbacks
2. A QueryWorkflow command handler in WorkflowFuture::handle_job that looks up in said hashmap and executes the callback
3. A SubscribeQuery variant to RustWfCmd enum together with a corresponding match branch
4. A register_workflow method for WfContext that populates the hashmap by calling RustWfCmd::SubscribeQuery

If I'm not missing something non-trivial, this should be rather straightforward.

[Sushisource]

@Elvecent Yep that's pretty much all right (though I think in 4 you meant to name it register_query_handler or similar).

[Elvecent]

I think a hit the gotcha. I don't see a way to complete the query request after the result is computed in WorkflowFuture::handle_job

[Sushisource]

@Elvecent I see, yes you'll need to plumb some way to include query responses in the outgoing commands for completion.

Probably the easiest thing to do would be to simply store a new list of query responses on the WorkflowFuture itself, and then drain those and include them in the completion inside of send_completion

[Elvecent]

@Sushisource Could you please clarify what do you refer to as send_completion? I'm not sure where to look for it

[Sushisource]

@Sushisource Could you please clarify what do you refer to as send_completion? I'm not sure where to look for it

It's a method defined on WorkflowFuture

[c-thiel]

@Elvecent did you ever manage to finish your implementation or have a work in progress somewhere that you could share?

[Elvecent]

@c-thiel here's what I have: https://github.com/Elvecent/sdk-core/tree/queries I ended up not needing it, though, so it's hardly tested