I am wondering if this library should provide support for highload interaction with RDS Data API?
RDS-serverless is great AWS service, but it has a tons caveats within highload interoperation. For example, DML query result can be received as error, although it had been successfully fulfilled, or transaction commit can be reported as successful, although it had been rollbacked.
There are minimum four known highload RDS Data API issues: https://redd.it/i3gnpz/ , https://redd.it/g0h4jq/ , https://redd.it/i4qcz1 , https://redd.it/f6ag4c/
Some of that issues can be wrapped around in library code by introducing auto-retries on AWS temporary errors and performing additional queries on ambiguous results, which had been caused by RDS-service errors.
At least following RDS services wrappers are mandatory: https://git.io/JUS3K and https://git.io/JUS36 , including inspecting error message name, type, code, message and stack, depend on current error.
I am wondering if this library should provide support for highload interaction with RDS Data API?
RDS-serverless is great AWS service, but it has a tons caveats within highload interoperation. For example, DML query result can be received as error, although it had been successfully fulfilled, or transaction commit can be reported as successful, although it had been rollbacked.
There are minimum four known highload RDS Data API issues: https://redd.it/i3gnpz/ , https://redd.it/g0h4jq/ , https://redd.it/i4qcz1 , https://redd.it/f6ag4c/
Some of that issues can be wrapped around in library code by introducing auto-retries on AWS temporary errors and performing additional queries on ambiguous results, which had been caused by RDS-service errors.
At least following RDS services wrappers are mandatory: https://git.io/JUS3K and https://git.io/JUS36 , including inspecting error message name, type, code, message and stack, depend on current error.