-
Notifications
You must be signed in to change notification settings - Fork 25
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
WFQ Tests & Utilities #641
Conversation
@@ -676,6 +677,7 @@ export class DBOSExecutor implements DBOSExecutorContext { | |||
) { | |||
// TODO: Make this transactional (and with the queue step below) | |||
args = await this.systemDatabase.initWorkflowStatus(internalStatus, args); | |||
await debugTriggerPoint(DEBUG_TRIGGER_WORKFLOW_ENQUEUE); |
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 this will add overhead to non-debug production workloads? If so, can we disable this in prod?
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.
Would be extremely surprised if the overhead is measurable.
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.
In this case, where it is against several database updates, I agree. However, disabling in prod is not a bad idea.
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.
We could get it down to a boolean check pretty easily. But we can do it later.
Move queue check code into system DB
A way to intercept code at various places during test and recreate scenarios that may depend on timing holes.