-
So we’re currently using DA.Validation - do you recommend using try-catch exception handling instead to be able to leverage rollbacks using the catch block?
-
I assume there is absolutely no way to prevent a batch from failing if a single command has an error unrelated to business logic, such as a failed fetch. In such cases, is there any way to know which command failed in the batch? Since there is no commandId at the command level, only at the batch level. For cases where a command in a batch fails, the app needs to be able to resubmit the rest of the commands with the erroneous one filtered out. Without knowing which specific command in the batch failed, it is quite cumbersome and (more importantly) it will not meet our SLAs, to use a recovery process like the one suggested here. Even if all commands were successful in a batch, a client app often needs to know which event was the result of which command. Is there a reason the commandId is not part of the Event payload itself, allowing easier correlation between the two?
-
Thank you for the great explanation and code samples on deduplication using contract keys, but the reason we didn’t want to go that way is because it will only work for active contracts, so we’d need to keep the contracts whose existence decides whether it’s a duplicate request or not, active, for the entirety of the deduplication period, which is atleast a week. This would mean an ACS that’s 2-4 times larger than it would’ve been otherwise, which would likely impact performance. We will likely try this out though to get actual numbers. I’m assuming you recommend against the approach of a single contract that stores a List/Set of requestIds for a week, because of its size and the need to search that list of millions of requestIds which will be too slow for latency sensitive (1.5-2s) workflows?