-
Notifications
You must be signed in to change notification settings - Fork 11
feat(temporal): detect Go in-workflow query/signal/update handler declarations #78
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
Merged
+278
−0
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.
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.
@avfirsov I need to think about it. My main concern for now: why not do the same as with the
Registerkind?In such a case, it could be
without exploding the schema.
I'll take a look at other PRs and return to this point later. There might be benefits for resolution purposes, so I'm not sure atm.
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.
Good question — and you're right that the
goDeferredCallfield is the part worth trimming. Let me separate the two axes, because I think they answer your "benefits for resolution?" doubt:The
viavalue is the real schema; the struct field is just a parser-internal carrier. The reason I didn't fold this intotempKindis that handler declarations sit on a different axis than dispatch/register:temporal.stub(ExecuteActivity) andtemporal.registerare about the activity/workflow namespace, andtemporal.stubedges get rewritten byResolveTemporalCalls(placeholder → real function). ThetempKindvalues (activity/workflow/register_activity/register_workflow) all live on that one axis and feed that one resolver pass.temporal.handleris the query/signal/update namespace and is not rewritten — it's pure provider metadata (“this workflow serves querystatus”), the Go-side counterpart of Java's@QueryMethod/@SignalMethod/@UpdateMethodannotation edges. A distinctvialets a consumer ask "all handlers" (via == "temporal.handler") without decoding ahandle_*prefix out oftempKind, and keeps the dispatch-intercept condition (tempKind == "activity" || "workflow") untouched.So I'd keep the distinct
via=temporal.handler(different namespace, different resolver treatment), but I fully agree about not adding the field. I can droptempHandlerKindand carry it astempKind = "handle_" + kind, withapplyGoTemporalHandlerMetarouting on that prefix — exactly mirroringregister_. Same for thetempOutKindfield in #81 (signalout_/querycall_). That removes the schema growth you're flagging while preserving the semantic/viadistinction.No rush — happy to push that refactor whenever you've settled on the direction (or leave it as-is if you decide the separate field reads cleaner). Thanks for taking the time across the three PRs.