resty icon indicating copy to clipboard operation
resty copied to clipboard

Fix multipart file readers not being reset when doing a retry

Open nikplx opened this issue 2 years ago • 2 comments

As mentioned in https://github.com/go-resty/resty/issues/166 by @neganovalexey, when doing a retry on a multipart request the io.Reader is not reset to the start again. This can lead to subtle bugs, as the request will be retried, but the form part of the file will be empty, because the reader was already exhausted. Solving this issue in the caller code is pretty ugly, because Request does not expose access to multipartFiles and so the caller would have to use RetryHooks and recreate the Response.Request and that at each call site (where there is access to the original ReadSeeker).

In the PR, I created a new client options SetRetryResetReaders which adds a retry hook seeking the start of each reader in multipartFiles, if the reader it got also implements io.ReadSeeker. This solved the above issue described above for my usecase and should have minimal implications on existing usages.

nikplx avatar Jun 15 '22 10:06 nikplx

What about the readers that cannot be reset?

SVilgelm avatar Jun 15 '22 17:06 SVilgelm

@SVilgelm They won't be reset. The code only resets the reader if it implements io.ReadSeeker and that only if you enable it, so as to not break any existing code. Every other reader will be untouched. I don't know if there is a usecase for passing in a reader that should not be reset, but it will not do anything if there is a reader that can not be reset.

nikplx avatar Jun 21 '22 11:06 nikplx

@nikplx I'm sorry for the delayed attention on the PR. Thanks for your contribution.

jeevatkm avatar Mar 06 '23 00:03 jeevatkm

@nikplx I'm sorry for the delayed attention on the PR. Thanks for your contribution. Yes, it make sense to provide the reset readers option for resty users.

jeevatkm avatar Mar 06 '23 00:03 jeevatkm

Hey @jeevatkm

I fixed the test stage. There was some mixup in the sum file. It now runs locally. Maybe you can retrigger the pipeline if you have some time.

nikplx avatar Mar 06 '23 07:03 nikplx

Codecov Report

Merging #549 (23e9fef) into master (0451c4c) will decrease coverage by 0.11%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #549      +/-   ##
==========================================
- Coverage   95.94%   95.84%   -0.11%     
==========================================
  Files          10       10              
  Lines        1357     1372      +15     
==========================================
+ Hits         1302     1315      +13     
- Misses         34       36       +2     
  Partials       21       21              
Impacted Files Coverage Δ
request.go 95.47% <ø> (ø)
client.go 97.78% <100.00%> (+0.01%) :arrow_up:
retry.go 100.00% <100.00%> (ø)
util.go 94.44% <0.00%> (-1.12%) :arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

codecov[bot] avatar Mar 06 '23 09:03 codecov[bot]

@nikplx This time PR validation build executed without any issue.

Do you mind checking this codecov feedback?

jeevatkm avatar Mar 06 '23 09:03 jeevatkm