AWS neptune documentation change
Summary
Updated retry logic guidance to specify exceptions that should not be retried (syntax errors, authentication failures, invalid queries) and added recommendations for exponential backoff with jitter and maximum retry limits
Security assessment
The change adds security best practices by warning against retrying authentication failures (which could indicate credential issues) and preventing resource exhaustion through retry limits, but doesn't address a specific security vulnerability
Diff
diff --git a/neptune/latest/userguide/best-practices-opencypher-retry-logic.md b/neptune/latest/userguide/best-practices-opencypher-retry-logic.md index 1cb538c16..b8f186c03 100644 --- a//neptune/latest/userguide/best-practices-opencypher-retry-logic.md +++ b//neptune/latest/userguide/best-practices-opencypher-retry-logic.md @@ -9 +9,3 @@ -For all exceptions that allow a retry, it is generally best to use an [exponential backoff and retry strategy](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) that provides progressively longer wait times between retries so as to better handle transient issues such as `ConcurrentModificationException` errors. The following shows an example of an exponential backoff and retry pattern: +Not all exceptions should be retried. For example, syntax errors, authentication failures, or invalid queries should not trigger a retry. For exceptions that do allow a retry, use an exponential backoff strategy with jitter to progressively increase the wait time between retries and avoid synchronized retry storms. Set a reasonable maximum number of retries to prevent infinite loops and resource exhaustion. For detailed guidance on developing a practical retry strategy, see [Exception Handling and Retries](./transactions-exceptions.html). + +The following shows an example of an exponential backoff and retry pattern for handling `ConcurrentModificationException` errors: