Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: enable reuse of FromData instance #6853

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

GLGDLY
Copy link

@GLGDLY GLGDLY commented Aug 1, 2022

I have been facing a situation that an API I was requesting would have some retryable error especially with form-data requests. While with reusing the FormData instance in my request, the RuntimeError was raised. In this case, I was confused that why the FormData instance would raise error upon re-gen.

With looking into the source code of aiohttp, I cannot discover any possible errors that may occurs with the reuse of FormData instance, especially the MultipartWriter seems to be designed with the ability to write() for more than once. As a result, I tried the change in this pr in my own code to test and proved that the resulting form-data to be send is correctly outputted.

To work more, with the fact that MultipartWriter seems to be designed for more than one time usage, the FormData may also accept further adding fields into the writer after already generated form data for a certain number of times. With this, it might be more flexible for we to deal with form-data request.

What do these changes do?

  • do not raise RuntimeError with the reuse of FormData instance but returning self._writer
  • after already generated form data for a certain number of times, allow adding more fields to further-update the MultipartWriter instance

Are there changes in behavior for the user?

Users may reuse the FormData instance without the need of creating a new instance for every form-data requests.

Related issue number

n/a

Checklist

  • I think the code is well written
  • Unit tests for the changes exist
  • Documentation reflects the changes
  • If you provide code modification, please add yourself to CONTRIBUTORS.txt
    • The format is <Name> <Surname>.
    • Please keep alphabetical order, the file is sorted by names.
  • Add a new news fragment into the CHANGES folder
    • name it <issue_id>.<type> for example (588.bugfix)
    • if you don't have an issue_id change it to the pr id after creating the pr
    • ensure type is one of the following:
      • .feature: Signifying a new feature.
      • .bugfix: Signifying a bug fix.
      • .doc: Signifying a documentation improvement.
      • .removal: Signifying a deprecation or removal of public API.
      • .misc: A ticket has been closed, but it is not of interest to users.
    • Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."

- do not raise RuntimeError with the reuse of FormData instance but returning self._writer
- after already generated form data for a certain number of  times, allow adding more fields to further-update the MultipartWriter instance
@GLGDLY GLGDLY requested a review from asvetlov as a code owner August 1, 2022 14:56
@GLGDLY GLGDLY requested a review from webknjaz as a code owner August 1, 2022 14:58
@psf-chronographer psf-chronographer bot added the bot:chronographer:provided There is a change note present in this PR label Aug 1, 2022
@@ -132,8 +131,8 @@ def _gen_form_urlencoded(self) -> payload.BytesPayload:

def _gen_form_data(self) -> multipart.MultipartWriter:
"""Encode a list of fields using the multipart/form-data MIME format"""
if self._is_processed:
raise RuntimeError("Form data has been processed already")
if not self._fields:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is safe to reprocess since it looks like get_payload supports streaming payloads which may only be able to be consumed once

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, if we want to support this (and I've no idea if we do), then we'd probably need to subclass this, or have different logic depending on the type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bot:chronographer:provided There is a change note present in this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants