NULL Item in Personalizations

[mlammert]

Issue Summary

We are sending the same individual email to 100s/1000s of users with substitutions so that certain parts of the email are unique to the individual recipient.

I believe my logic is sound and as you will see below the resulting JSON payload look correct, except for one thing. The first item in the personalizations array is NULL.

Steps to Reproduce

Here is some truncated code that we are using. Since SendGrid can only process 1,000 emails at a time, we chunk the returned array of users from the database into separate arrays. So, for example, if we have to send 3,000 emails, this will chunk into 3 ($i) and then the personalization will loop through the users in those chunks ($j). This will result in making 3 requests of 1,000 personalized emails.

This all works great.

for ($i = 0; $i < $intNumberOfChunks; $i++) {

    $objSendGrid = new SendGrid(SENDGRID_API_KEY);
    $objEmail = new SendGrid\Mail\Mail(); 
					
    $objFrom = new SendGrid\Mail\From(EMAIL_FROM_ADDRESS, EMAIL_FROM_NAME);
    $objEmail -> setFrom($objFrom);
					
    $objSubject = new SendGrid\Mail\Subject("test subject");
    $objEmail -> setSubject($objSubject);
				
    $objContent = new SendGrid\Mail\Content("text/html", "test content");
    $objEmail -> addContent($objContent);

    for ($j = 0; $j < count($arrChunkedUserEmails[$i]); $j++) {

        $objPersonalization = new SendGrid\Mail\Personalization();

        $objTo = new SendGrid\Mail\To($arrChunkedUserEmails[$i][$j], $arrChunkedUserFirstNames[$i][$j] . " " . $arrChunkedUserLastNames[$i][$j]);
        $objPersonalization -> addTo($objTo);

        $objPersonalization -> addSubstitution("{{firstname}}", $arrChunkedUserFirstNames[$i][$j]);

        $objPersonalization -> addSubstitution("{{lastname}}", $arrChunkedUserLastNames[$i][$j]);
    
        $objEmail -> addPersonalization($objPersonalization);

    }

    echo(json_encode($objEmail, JSON_PRETTY_PRINT));

    $response = $objSendGrid -> client -> mail() -> send() -> post($objEmail);

}

The trouble comes when I view the JSON of the $objMail. Here is a truncated example of the JSON payload I get.

"personalizations": [
    null,
    {
        "to": [
            {
                "name": "User One",
                "email": "user@one.com"
            }
        ],
        "substitutions": {
            "{{firstname}}": "User",
            "{{lastname}}": "One"
        }
    },
    {
        "to": [
            {
                "name": "User Two",
                "email": "user@two.com"
            }
        ],
        "substitutions": {
            "{{firstname}}": "User",
            "{{lastname}}": "Two"
        }
    }
],
"from": {
    "name": "Test From",
    "email": "test@from.com"
},
"subject": "test subject",
"content": [
    {
        "type": "text\/html",
        "value": "test content"
    }
]

The JSON payload looks correct except for the first NULL item personalization array.

Does anybody know why the NULL is being inserted?

Thanks!

EDIT: I just noticed the person in ISSUE #650 was having a very similar issue to me with the NULL personalization item. I implemented the fix (inserting a from address in the mail constructor) and it seems to have worked.

new Mail(new From('noreply@domain.com, 'AppName'));

My question now is why does the NULL issue happen? And, how does inserting a from address into the mail constructor fix it? Nowhere in any docs have I seen the from address inserted directly into the mail constructor.

Technical details:

• sendgrid-php Version: master (latest commit: 7.2.0)
• PHP Version: 5.6.35 via WAMP3

[thinkingserious]

Good catch @mlammert! I've added this to our backlog for further investigation.

When you use the constructor, we create a default personalization object for you. I believe that is probably the source of this odd behavior.

With Best Regards,

Elmer

[mlammert]

@thinkingserious

So, I know inserting the from address in the mail constructor seems to get rid of the NULL item. However, that seems sort of "hack-ish" to me.

Is there a better recommended way to remove the NULL item from the personalziation array?

Thanks!

[thinkingserious]

I agree @mlammert, this is not expected behavior. This issue is currently on our backlog for an investigation and fix. Thanks!

[remyapv]

@thinkingserious

Did some debugging here:

If there’s no parameters passed to \SendGrid\Mail\Mail constructor, it initiates personalization attribute with an empty Personalization instance immediately followed by a return.

if (!isset($from)
    && !isset($to)
    && !isset($subject)
    && !isset($plainTextContent)
    && !isset($htmlContent)
    && !isset($globalSubstitutions)
) {
    $this->personalization[] = new Personalization();
    return;
}

I couldn’t see any specific reason for initialising like this. Please correct me if I’m wrong here.

If this initialisation is removed the above mentioned issue will get resolved.

Please let me know as I’m happy to help here.

[thinkingserious]

Hi @remyapv,

I believe the purpose of that initialization was to make sure there was at least on personalization created when you create a Mail object.

But I think you are right, by doing that we cause more confusion and our Kitchen Sink example would not work properly.

This issue is all yours :)

Thanks!

With Best Regards,

Elmer

[reisraff]

@thinkingserious can you please take a look at the patch?

[mercredo]

currently migrating from 5.0.4 to 7.3.0.

searched for hours, and this solved my {"errors":[{"message":"Invalid type. Expected: object, given: null.","field":"personalizations.0","help":null},{"message":"Invalid type. Expected: object, given: string.","field":"personalizations.1.to.0","help":"http://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/errors.html#message.personalizations.to"},{"message":"Invalid type. Expected: object, given: string.","field":"personalizations.2.to.0","help":"http://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/errors.html#message.personalizations.to"}]} api error.

the doc didnt give me any hints for that. 😕

[thinkingserious]

Looking now @reisraff.

My apologies @mercredo! It looks like we should be able to merge and deploy @reisraff's patch.

[childish-sambino]

Fixed by #705