wenjin272 commented on issue #1105: URL: https://github.com/apache/flink-agents/issues/1105#issuecomment-5599677729
Thanks for raising this question. I don't think we need to persist the retry counter separately. Although the local `attempt` variable is reset when the action restarts, each completed `durableExecute` call—including a failed call—is already persisted as a `CallResult`. During recovery, the retry loop starts from zero, but the previously persisted failures are replayed in order: each cached failure advances the durable call index and is rethrown, which naturally advances the loop back to the correct attempt without invoking the model again. For example, if attempts 0 and 1 failed before the restart, recovery will replay those two failures for loop iterations 0 and 1, and the next physical model invocation will still be attempt 2. Therefore, the physical retry budget should not reset for failures that were successfully recorded. There is a separate in-flight ambiguity if the job fails while a model request is running, or after it completes but before its result is persisted. That may cause the request to be executed again, but persisting only the retry counter would not fully solve it; strict deduplication would require reservation plus provider-side idempotency or reconciliation. Since this is primarily a question about the intended behavior rather than a confirmed bug or feature request, the Discussions Q&A category may be a better place for this kind of question. -- 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]
