dhiaayachi
commented
2 months ago Thanks for the feature request. We appreciate the detailed description of your use case.
As a workaround, you could consider using a global key-value store like Redis or a database and using it to correlate between the two unique IDs.
We'll keep this request in mind as we prioritize features for future releases.
Is your feature request related to a problem? Please describe. I want to connect GitHub webhooks to temporal. In particular, I want to run a GH actions workflow as an activity in my temporal workflow. This is not modelled really well with signals in the workflow: From receiving a workflow_run event, it's usually unclear which temporal workflow triggered this run. Also, mixing control flow and signals is imo not very nice. I'd rather have this abstracted inside an activity (with timeouts, retry, etc).
So, I want to (and am) using an async activity. The problem with that is that for that, I am getting a unique ID (task token) from temporal, and I'm getting another unique ID from GitHub (workflow_run_id). I now have to manually correlate those two (in my case: By using a database table on the side that is accessible to both the temporal worker that starts the actions workflow, and the temporal client, that receives the GH webhooks). This works well, but I'd rather not maintain a database myself.
Describe the solution you'd like Provide the same async activity mechanism, but with an API where I hand temporal a unique ID (I have to promise uniqueness as part of the API contract, otherwise temporal is expected to throw an error), instead of getting a unique Id from temporal. I think that would lend itself neatly to all sorts of webhook-receiving problems, where the system you're integrating against hands out unique IDs. I believe in many cases, async activities will model flows in external systems much better than signal handlers in workflows, as activities compose much better (and are easier to be reused as well!) than signal handlers, that are rather workflow-specific.
Describe alternatives you've considered See above, I can manually map the IDs between the different systems. For that to be easier, a general-purpose KV-store exposed by temporal would also be appreciated, as then I don't need to manually maintain the database+database table+migration myself.
Additional context I'm happy to answer any more questions about our use case.