resumable-stream

Description The current implementation has a hardcoded 1000ms timeout that makes the system fragile in unstable network conditions. Problem Code Issues 1. Hardcoded timeout is inflexible: The 1000ms timeout cannot adapt to different network environments 2. Too aggressive: 1 second may be insufficient for high-latency or unstable networks 3. Confusing logic: The delay and the timeout check both use 1000ms, meaning the timeout error will almost always trigger when the timer fires Impact Systems fail unnecessarily in slower network conditions No way for users to configure timeout based on their environment Production deployments in high-latency regions become unreliable Suggested Solutions Option 1: Configurable Timeout Option 2: Retry with Backoff Implement exponential backoff retry logic instead of a single hard timeout. Environment Network latency: Variable (100ms - 2000ms in our production) This affects production stability Would you be open to a PR implementing configurable timeouts? ```