bdoyle0182 commented on a change in pull request #5169:
URL: https://github.com/apache/openwhisk/pull/5169#discussion_r759480654
##########
File path:
common/scala/src/main/scala/org/apache/openwhisk/core/database/ActivationStore.scala
##########
@@ -35,21 +35,25 @@ case class UserContext(user: Identity, request: HttpRequest
= HttpRequest())
trait ActivationStore {
protected val disableStoreResultConfig =
loadConfigOrThrow[Boolean](ConfigKeys.disableStoreResult)
+ protected val disableStoreNonBlockingResultConfig =
loadConfigOrThrow[Boolean](ConfigKeys.disableStoreNonBlockingResult)
protected val unstoredLogsEnabledConfig =
loadConfigOrThrow[Boolean](ConfigKeys.unstoredLogsEnabled)
/**
* Checks if an activation should be stored in database and stores it.
*
* @param activation activation to store
* @param isBlockingActivation is activation blocking
+ * @param disableBlockingStore do not store activation if successful and
blocking
+ * @param disableNonBlockingStore do not store activation if successful and
non-blocking
Review comment:
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
