davidradl commented on PR #33: URL: https://github.com/apache/flink-connector-http/pull/33#issuecomment-4396794344
> You're absolutely right — the lookup source has a comprehensive retry configuration system with `retry-strategy.type`, `retry-codes`, `success-codes`, and separate config for fixed-delay vs exponential-delay strategies. The sink should have the same level of control for consistency. > > The current PR provides a **minimal viable retry** implementation with just `http.sink.retry.times` and a simple exponential backoff (1s, 2s, 4s, ...). This is a significant improvement over no retry support at all, but it's clearly not feature-complete compared to the lookup source. > > I see two paths forward: > > **Option 1: Extend this PR** to match the lookup source pattern: > > * Add `http.sink.retry-strategy.type` (fixed-delay | exponential-delay) > * Add `http.sink.retry-codes` (which HTTP status codes trigger retry) > * Add `http.sink.success-codes` (define success conditions) > * Add all the delay configuration options (initial-backoff, max-backoff, multiplier) > * This would make the sink and lookup source retry configurations consistent > > **Option 2: Merge basic retry now, extend in follow-up**: > > * Current PR provides immediate value (basic retry is better than none) > * Follow-up PR adds full retry strategy configuration to match lookup source > * Allows incremental delivery > > Which approach would you prefer? I'm happy to extend this PR to include the full retry configuration system if that's the direction you'd like to go. It would take a bit more time to implement and test, but would give us feature parity with the lookup source in one shot. Option 1 looks good - as it is then consistent with the lookup -- 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]
