-
Notifications
You must be signed in to change notification settings - Fork 1.2k
add system config options for success / failure levels to write blocking / non-blocking activations to db #5169
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
bdoyle0182
merged 10 commits into
apache:master
from
qualtrics:add-config-to-not-save-successful-nonblocking
Feb 1, 2022
Merged
Changes from 2 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
af7cb02
add config option to disable successful non-blocking activation write…
5881bc6
fix check
7916d90
feedback
5e2b36f
Merge branch 'master' into add-config-to-not-save-successful-nonblocking
a3db5d3
fix tests
e43ee00
Merge branch 'master' into add-config-to-not-save-successful-nonblocking
823e3e9
rebase
7bbac30
feedback
4a4a083
update config precedence
666b707
Apply suggestions from code review
bdoyle0182 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
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
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
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.
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.
Widening the signature here this way strikes me as confusing - couldn't this be better done with an enum:
always store
,never store
,store for non blocking only
, etc?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 guess my question would be how could you do that without breaking the config that already exists for
disableBlockingStore
that's presumably already being used?The other thing is I think people still want to distinguish between successful and failures so they only want to turn off writes for successes. I'm not sure what the best solution is or what options should be offered.
I think I understand your suggestion in that there could be an enum set with values
ALWAYS_STORE_SUCCESSES
,STORE_BLOCKING_SUCCESSES
,STORE_NONBLOCKING_SUCCESSES
,STORE_NO_SUCCESSES
. However I think doing this would break deployments unless we kept it as two booleans in the config as currently is in the pr and built the enum from the boolean values. But I think that defeats the purpose of setting up the enum at all.And then on our discussion for our use case specifically with only needing specific failure types written (developer and system). I think that should be a separate check which could either be an enum or just a boolean of
storeApplication Errors
since I think developer and system errors both are very similar in what they mean. The divider in failures to me is really just whether it's a user application error or not.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 think there are two orthogonal issues - one is configuration and making that backward compatible. The other is the internal interface and implementation.
I think the distinctions you want to make suggests this alternate/simpler enum:
STORE_ALWAYS
(default)STORE_ON_FAILURE
STORE_NON_BLOCKING
From a configuration point of view, you can continue to accept the current configuration property (perhaps with a deprecation warning) and introduce a new configuration that maps to the enum. It would be an error to specify both configurations properties.
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 agree with that setup. The one case that I think is confusing is the existing boolean and wanting failed blocking activations to still be stored. Because setting the current boolean means store failed blocking activations and non-blocking activations. So that falls between
STORE_ON_FAILURE
andSTORE_NON_BLOCKING
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 thinking that
STORE_ON_FAILURE
applies to everything. I suppose we can have two modes for this:STORE_ON_FAILURE_BLOCKING_AND_NON_BLOCKING
for sync/async andSTORE_ON_FAILURE_NON_BLOCKING_ONLY
(and so OK there are four again :)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.
This is what I have. I can't think of a scenario where someone would want a subset of non blocking activations written, but not a larger subset for blocking. I can only think of wanting a subset of blocking and wanting a larger subset for non-blocking. I'll update the pr if you're good with this
STORE_ALWAYS
STORE_NON_BLOCKING_OR_ON_BLOCKING_FAILURE
STORE_ON_FAILURE
STORE_ON_NON_APPLICATION_FAILURE
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.
STORE_NON_BLOCKING_OR_ON_BLOCKING_FAILURE
andSTORE_ON_FAILURE
are redundant for blocking invokes, no? That is, to store all non blocking I'd useSTORE_NON_BLOCKING_OR_ON_BLOCKING_FAILURE
and to only store non blocking failures, I'd useSTORE_ON_FAILURE
and to store blocking failures, i can use either. (I think the parameters should be orthogonal.)I like the addition of
STORE_ON_NON_APPLICATION_FAILURE
- It further refines the on failure mode - so this would capture system errors and uncaught exceptions in the end user code.Another crank on your suggestions nets us here, perhaps?
STORE_ALWAYS
(default)STORE_NON_BLOCKING
STORE_FAILURES
STORE_FAILURES_NOT_APPLICATION_ERRORS
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.
Yea so what I was originally going to say as well is that I think we're just getting close to having a separate config for each invocation type, blocking and non-blocking. In your list, the original person that created the blocking config wanted only blocking failures and all non-blocking; which is why I had
STORE_NON_BLOCKING_OR_ON_BLOCKING_FAILURE
. Almost everyone would want this because not storing any non-blocking means you can't run sequences I believe, we don't have any need for that feature which is why we can turn off non-blocking. But you are correct that would mean the parameters aren't orthogonal, which is why I think we're at the point of just having two separate params with the same enum.STORE_ALWAYS
STORE_FAILURES
STORE_FAILURES_NOT_APPLICATION_ERRORS