spangaer commented on PR #11: URL: https://github.com/apache/pekko-persistence-dynamodb/pull/11#issuecomment-2420265899
Well, that escalated quickly 😛. I'm a bit in limbo on the matter: 1. On the one hand, this is just extending on the behavior that was already there. It already retried on `ProvisionedThroughputExceededException`, which is a 400 status error nota bene. It's just adding adjacent errors and back-end network glitches to it. 2. On the other hand, yes there will always be those that have lived with the errors so far and possibly have built workarounds on top. TBH, point 2 seems a bit of a bad reason to leave it configurable, as this seems like "the better solution". The current structure also doesn't lend itself too well for config, so it's a bit of a refactor. But if you insist anyway, I guess I can look in to that. Seems like it probably deserves a split, so you can selectively opt-out of 50x vs 400 codes at the very least. Per exception is probably over the top? At the extreme it could use reflection to configure a recovery selector implementation. Which would overrule the internal API statement. But I think that strategy would be a little over the top? 🤷 -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
