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

Mail.add_header doesn't accept a dict #997

Open
tzachyrm opened this issue Jul 22, 2021 · 2 comments
Open

Mail.add_header doesn't accept a dict #997

tzachyrm opened this issue Jul 22, 2021 · 2 comments
Labels
status: help wanted requesting help from the community type: bug bug in the library

Comments

@tzachyrm
Copy link

tzachyrm commented Jul 22, 2021

Issue Summary

The docs mentions that the Mail.add_header should accept a dict of key-value pairs. However, when passing a dict, the function fails.

Steps to Reproduce

  1. Initialize a new Mail object
  2. Call add_header with a dict. According to the docs this should work.

Code Snippet

from sendgrid .helpers.mail import Mail
Mail().add_header({"X": "y"})

Exception/Log

Traceback (most recent call last):
  File "/env/lib/python3.8/site-packages/sendgrid/helpers/mail/mail.py", line 466, in add_header
    if header.personalization is not None:
AttributeError: 'dict' object has no attribute 'personalization'

Technical details:

  • sendgrid-python version: 6.7.1
  • python version: 3.8
@eshanholtz eshanholtz added status: help wanted requesting help from the community type: bug bug in the library labels Jul 23, 2021
@eshanholtz
Copy link
Contributor

This issue has been added to our internal backlog to be prioritized. Pull requests and +1s on the issue summary will help it move up the backlog.

@hassaku63
Copy link

hassaku63 commented May 4, 2022

I sent a pull request for code to fix this issue.

As I mentioned in the pull request, the current implementation seems intended to only add the first key/value item if the header argument given to add_header is dict that has multiple key/values.

I believe this is non-intuitive and confusing to users. However, as long as the intent is not clear, I did not think this should be changed and kept it as is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: help wanted requesting help from the community type: bug bug in the library
Projects
None yet
Development

No branches or pull requests

3 participants