-
Notifications
You must be signed in to change notification settings - Fork 107
Named signal handlers #157
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
Conversation
antstorm
left a comment
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.
See inline comments
| # Optionally, we may register a named handler that is triggered when an event _and | ||
| # an optional handler_name key_ are provided. When this more specific match | ||
| # fails, we fall back to matching just against +event_name+. | ||
| # |
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.
I feel like a cleaner solution would be to add the handler_name to event_name and dispatch the event twice:
- "signaled:signalName"
- "signaled"
I think this would keep the dispatcher simpler for now and does allow us to achieve everything that is needed
lib/temporal/workflow/dispatcher.rb
Outdated
| event_struct.event_name == WILDCARD | ||
| end | ||
|
|
||
| def sanitize_handler_name(event_name, handler_name) |
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.
I wonder if we should let the called to this instead of handling it in the Dispatcher ^. Basically I'm thinking that we can leave the Dispatcher's API unchanged and just allow the caller to construct the event name the way they want.
Another approach might be to actually use the target to represent a signal itself, then what you can do is:
signal = Signal.new(signal_name)
dispatcher.register_handler(signal, 'signaled') { |input| ... }and for a catch-all:
dispatcher.register_handler(Dispatcher::TARGET_WILDCARD, 'signaled') { |signal, input| ... }I'm a bit hesitant to extend the Dispatcher's interface because I feel like we can achieve what we need with the current version and can avoid overcomplicating it
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.
As you see, I tried to move the naming logic into Dispatcher. I agree that it changes the Dispatcher interface but now the complexity will move elsewhere.
I like the second suggestion about making a Signal object. I'll try that first since it preserves some encapsulation without leaking it to multiple classes.
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.
Ended up going with the first suggestion. I couldn't figure out how to do it the second way with a Signal class. In StateManager#apply_event it never popped a Signal target so no events ever matched it. I'm sure I missed something simple but I ran out of time to dig into it. More documentation here about how elements get onto the History::EventTarget queues might be useful (unless this concept is going away in the rewrite).
lib/temporal/workflow/context.rb
Outdated
| call_in_fiber(block, input) | ||
| end | ||
| else | ||
| dispatcher.register_handler(target, Dispatcher::WILDCARD) do |signal, input| |
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.
Something is missing here. This will basically call the handler on every single event dispatched on the History::EventTarget.workflow
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.
I was worried about that but unsure. You confirmed it was wrong. Just pushed a change more in line with your earlier guidance using Dispatcher::TARGET_WILDCARD, 'signaled' instead. Hopefully that won't get executed for all workflows whenever a signal arrives.
antstorm
left a comment
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.
🎉 🎉 🎉
Support for named signal handlers, e.g.
on_signal('SOME_NAME') { }. Always call the "catch-all" signal handler even when a named handler exists.