-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document signal catch and throw events #2708
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There are now two ways to broadcast signals. In 8.2, only the RPC could be used, but in 8.3 we've introduced signal throw events and signal end events. These events don't have their own documentation paragraphs yet, so I'll link them later. I've taken the opportunity to rewrite some sections to reuse specific words like broadcast and trigger.
Signal can have a negative performance impact starting from C8.3, where signals are broadcasted to all partitions and can trigger signal subscriptions of process instances. We must teach users about this impact. While I'd love to see some best practices for signal events in the future, I think it's enough for now to document the performance impact as reference details.
In 8.3, we introduce the ability to delete resources (processes/decisions). This can have an affect on signal start events when the process that contains them is deleted, or when the previous version contains them.
With 8.3, new signal catch and throw events have been introduced. I've added a description for them, and marked them as covered.
Intermediate signal events can also be attached to event-based-gateways. I've updated the description, example, and image.
christinaausley
previously approved these changes
Oct 7, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One non-blocking comment but looks good 👍
It's hard to tell users when to use signals and when they shouldn't. It's very dependent on independent use-cases. Instead of recommending, we should aim to inform the user. This is what this warning already does. With this information users can decide themselves if this fits their use-case.
remcowesterhoud
approved these changes
Oct 9, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @korthout 🙇 I only made one small fix the warning. Enjoy your holiday! 🍹
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This documents the signal catch and throw events that are newly supported in 8.3.
In 8.2, only the top-level signal start event was supported. With 8.3, support for all other signal events is added. See camunda/camunda#10777 for an overview of signals, or see the individual sections:
closes #2458
closes #1956
closes #1895
When should this change go live?
hold
label or convert to draft PR)?I think this will be described in the 8.3 release blog post, but I'm not sure.
PR Checklist
/versioned_docs
directory, or they are not for an already released version./docs
directory (aka/next/
), or they are not for future versions.