nima nikoonazar

I appreciate your point, but I don't think we can ignore the impact of human creativity on coding. You're right that automation can make many tasks easier and faster. However,...

Thank you for your support and feedback. I checked the Java code, and it currently allows for 2 retry attempts within the deadline. I have some ideas to improve this,...

@matt-hensley Thank you for sharing these valuable references and the link to the related issue. I checked the Java SDK code, and as you pointed out, it performs 2 retry...

can you review this PR? @lfoppiano @jasondavies @corygehr

Thanks for the heads-up! I mentioned you because my PR has been pending for a few months without any review, and since you’re listed as a member/contributor, I thought you...

Thanks for bringing this up. I completely agree that adhering to the spec is crucial, but the current behavior of potential infinite retries poses a significant safety risk (e.g., in...

Thanks for the feedback. To be clear, implementing a simple Time-based limit (e.g., hardcoded 30s timeout) is technically straightforward here. However, implementing a full pluggable/custom Backoff strategy involves a larger...

@pellared I completely understand and appreciate your caution regarding the public API surface. Stability is definitely key. I am glad we agree on the path forward. I will leave the...

I agree that hard-coding values is generally not ideal. Regarding the "Breaking Change" concern: The current behavior (infinite retries) is widely considered a defect, especially in serverless environments where it...

Thanks for the comment @alanwest . While I agree that the `Timeout` (default 10s) acts as a hard stop and prevents the process from hanging forever, relying solely on timeout...