search

dapr / dapr

Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
https://dapr.io
Apache License 2.0
24.13k stars 1.91k forks source link

[workflow] introduce workflow lifecycle events firehose #6072

Open olitomlinson opened 1 year ago

olitomlinson commented 1 year ago

/area runtime

Describe the proposal

@cgillum @nyemade-uversky

From an operational perspective, it makes sense that that we introduce a firehose of Workflow life-cycle events.

These are incredibly valuable for users who want an evented hook / trigger when a life-cycle event occurs.

This concept is not anything new, and is fully embraced in Azure Durable Function

I propose that the Workflow runtime uses Daprs Internal PubSub concept (same as how Dapr Outbox is implemented), to enable end-users to build their own solutions on top of the firehose of events.

List of use cases as to why this feature is needed

Use case 1 - Operations observability

A perfect and common example of this is subscribing to a firehose of failed events. This allows developers and operations people to keep track of critically important workflows and react accordingly, usually by raising alerts.

Use case 2 - Performance validation of the Workflows Runtime

I'm trying to test running many workflows at scale, but there is no easy way for me to see the state of my workflows. For example, if I schedule 10,000 workflows, I want to see 10,000 workflows complete eventually. There's no easy way for me to do this.

Having the lifecycle events would allow me to create a subscriber to persist the complete/failed events and easily aggregate them to check that I've achieved my goal.

Once again, lifecycle events are super important for driving monitoring/alerting in a production scenario.

Use case 3 - Driving internal implementations of Dapr Workflows capabilities & features

Another use-case of this feature would be to support the purging of instance data for dapr workflows.

Some users may want to only purge completed instances Others may want to only purge failed instances etc.

The lifecycle events would be subscribed by the Workflow app itself (via PubSub), and if a certain status is reached, the user-code would proceed to call Purge on that instance

This allows a flexible model to achieve each of those goals, with no additional complexity for dapr maintainers.

Use case 4 - Secondary indexes / Deprecated Workflow Type detection

Another use-case is for building a secondary index of instance IDs which can be used to drive a polling process which checks for versions of workflows which are no longer running I.e when looking to deprecate a particular version of a workflow type from the code base.

dapr-bot commented 1 year ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

olitomlinson commented 1 year ago

Bump

@cgillum how do we get this on the roadmap?

cgillum commented 1 year ago

@nyemade-uversky currently manages the roadmap for workflows, so I think we'll need her agreement to take this on.

I agree this would be a useful feature.

olitomlinson commented 1 year ago

It would be really advantageous to have this feature available.

I'm trying to test running many workflows at scale, but there is no easy way for me to see the state of my workflows. For example, if I schedule 10,000 workflows, I want to see 10,000 workflows complete eventually. There's no easy way for me to do this.

Having the lifecycle events would allow me to create a subscriber to persist the complete/failed events and easily aggregate them to check that I've achieved my goal.

Once again, lifecycle events are super important for driving monitoring/alerting in a production scenario.

@nyemade-uversky I really think this needs prioritising into the roadmap, ideally 1.12.

yaron2 commented 1 year ago

@nyemade-uversky currently manages the roadmap for workflows, so I think we'll need her agreement to take this on.

I agree this would be a useful feature.

I don't know what roadmap you are referring to, but what goes in 1.12 or later is decided and prioritized solely by @dapr/maintainers-dapr

olitomlinson commented 1 year ago

@yaron2 this is the roadmap that we're referring too :) https://github.com/orgs/dapr/projects/61#card-88408739

Sorry, wasn't trying to circumvent any process, but I thought @nyemade-uversky was in the drivers seat for what happens and when with regards to Workflows :) Happy to be wrong on that of course.

dapr-bot commented 1 year ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

olitomlinson commented 1 year ago

Bump

olitomlinson commented 1 year ago

Another use-case of this feature would be to support the purging of instance data for dapr workflows.

The lifecycle events would be subscribed by the Workflow app itself, and if a certain status is reached, the user-code would proceed to call a single high-level workflow management API to purge that specific workflow instance.

That API doesn't exist, but something like

POST http://localhost:3500/v1.0-alpha1/workflows/<workflowComponentName>/<instanceId>/**purge**

Some users may want to only purge completed instances Others may want to only purge failed instances etc.

This allows a flexible model to achieve each of those goals, with no additional complexity for dapr maintainers.

dapr-bot commented 1 year ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

olitomlinson commented 1 year ago

Bump

dapr-bot commented 10 months ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

olitomlinson commented 10 months ago

bump

dapr-bot commented 8 months ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

olitomlinson commented 8 months ago

Bump

dapr-bot commented 6 months ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

olitomlinson commented 6 months ago

Bump

olitomlinson commented 4 months ago

Another use-case is for building a secondary index of instance IDs which can be used to drive a polling process which checks for versions of workflows which are no longer running I.e when looking to deprecate a particular version of a workflow type from the code base.

cgillum commented 4 months ago

Agreed with the secondary index use case, which is a big gap in the current implementation.

Should we aggregate the list of potential use cases in the OP, for easier referencing?

olitomlinson commented 4 months ago

Should we aggregate the list of potential use cases in the OP, for easier referencing?

Yep good idea. done that!

dapr-bot commented 2 months ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.