Closed oromand closed 1 year ago
Hi @oromand,
From the error description, seems like the issue can be bound to the wrong JSON property type in the request, as well as with template itself. Could you please provide the full code, template code etc so I can look at it more deeply?
Also, there is always a faster way to understand what's wrong - When the HTTP status for the API call is 500, you will see ErrorIdentifier field. It will contain a reference to the error in our internal log and it is crucial for us to determine the root cause of the failure. Should you encounter such errors, please contact our support for additional investigation, providing this error identifier.
Hello @goacoustic and thanks for taking a look at my issue.
I did submit a ticket last week to the support, hoping to have someone to look at it.
Here are the detailed information, of my error. As I pointed out in my ticket, the template was duplicated from a working one. And strangely .. the new one would just not work. The call is made with API. I would paste the code later one. So to summarize the situation, same code with a given template would work. Duplicate the template and run the code would fail with below information.
ErrorMessage: "Wrong type for template header, expected type \"string\""
ErrorRelatedTo: sender
ErrorIdentifier: 8e21d334-4387-4630-858f-f4f768df62fc
ErrorCode: send-0019
Template Id: 2625051
This is the code used to trigger an templated email through API. The exact same code would work with some templates, but some other may fail with reported error.
var email = new TransactionalEmailBuilder()
.WithTo(new SendContact(to))
.WithFrom(new SendContact(_mailjetConfiguration.Mail.FromAddress, _mailjetConfiguration.Mail.FromName))
.WithSubject(subject)
.WithTemplateId(templateId)
.WithTemplateLanguage(true)
.WithTemplateErrorDeliver(true)
.WithTemplateErrorReporting(new SendContact("email@somedomain.fr"))
.WithVariables(variables)
.Build();
var response = await _emailClient.SendTransactionalEmailAsync(email);
After hearing from mailjet, I believe there's a side effect in the interface. The person didn't take my problem seriously and closed my ticket without prior notice.
Here's a reproductible case to follow
I believe I have some sort of reproductible case. The template ID I took from the mailjet gallery and instanciated is 2638484. To reproduce:
I got objected it couldn't be a bug since no one ever reported it ... Should I report this in the API though ?
Hi @oromand,
Seems like the real issue with the specific template.
Let me report it to the API team directly.
Hey Stanislav,
Thanks for taking the time to review my issue. I could reproduce the problem with a fresh account, a fresh template by just fiddling around with sender setup. The issue got reported twice but my ticket got closed thanks to automatic close policy, despite reproducible steps ..
One workaround I have been given is to remove the extra information through API, which I did, and it worked. But it's not for sure a viable solution.
Would you need more information ? I could give you the details steps,
Regards
Le mer. 26 mai 2021 à 01:58, Stanislav Diakovskiy @.***> a écrit :
Hi @oromand https://github.com/oromand,
Seems like the real issue with the specific template.
Let me report it to the API team directly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mailjet/mailjet-apiv3-dotnet/issues/69#issuecomment-848351008, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZLBXKRVUBLIIG236FNX5DTPQ2RPANCNFSM4ZAJXQPA .
-- Olivier ROMAND
We are facing the exact same issue and are able to confirm that the template duplication leads to the issue.
From our account any duplicated templates cannot be used via the mailjet-apiv3-dotnet API.
Using the API with this type of template leads to the following error systematically returned by the mailjet-apiv3-dotnet:
ErrorMessage: "Wrong type for template header, expected type \"string\""
ErrorRelatedTo: sender
ErrorIdentifier: 8e21d334-4387-4630-858f-f4f768df62fc
ErrorCode: send-0019
The same template content built from scratch works. The same template content built from an existing model works.
Is there any planned fix for this ? any branch reference or planned version ?
Thanks for keeping this issue opened and push it to the development team.
Regards,
Dear @jbconcept
After digging into this issue it doesn't appear to be related to the API. You can actually update the template and remove the extra field with the API correctly. Good luck if you are trying to report this issue to the support ..
I agree, probably due to the duplicate feature and nothing to do with the API itself.
Would you please let me know if you have a precise list of actions to be done to "repair" buggy templates ?
Regards,
Frédéric Zanaroli Architecte - Chef de projets
@.**@*.**@*.***> Tel : +33 (0)4 76 33 91 15 / Fax : +33 (0)4 76 33 38 94
JB Concept
2, rue de la viscose 38130 Échirolles http://www.jbconcept.frhttp://www.jbconcept.fr/
[cid:9f0a342f-fd37-4576-aeb3-9f476271e841][cid:7133a637-121b-42ae-9d5e-1e24b49b423c]
De : oromand @.> Envoyé : vendredi 11 juin 2021 16:34 À : mailjet/mailjet-apiv3-dotnet @.> Cc : Frédéric ZANAROLI @.>; Mention @.> Objet : Re: [mailjet/mailjet-apiv3-dotnet] Where to look for specific error code details ? (#69)
Dear @jbconcepthttps://github.com/jbconcept
After digging into this issue it doesn't appear to be related to the API. You can actually update the template and remove the extra field with the API correctly. Good luck if you are trying to report this issue to the support ..
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/mailjet/mailjet-apiv3-dotnet/issues/69#issuecomment-859625551, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKGRVXKD3CGX7RDFUZA2OUTTSININANCNFSM4ZAJXQPA.
Here're the detailed instructions on how get over it (given from support) It actually does work, which makes me think it doesn't have to see with the API. Once the template has been corrupted, even if the API cleans it, the corrupted values would come back if you hit save on the mailjet interface ...
What you can do in order to fix the template is to make a GET request on https://api.mailjet.com/v3/REST/template/$ID/detailcontent and copy the content from the response by removing the last line - "Sender": 000000 (which is actually causing the issue). Once done, you can created new template with this same content - POST with this payload on https://api.mailjet.com/v3/REST/template/$ID/detailcontent (by using the new template ID):
And these are the reproductible steps I gave to the mailjet support
To reproduce: Start a new template In the "edit subject" pane, go to Address and choose "Add a new adress", and then "Add an address on another domain". I believe the template gets corrupted at this point. In the screen that opens to enter a new domain, I went back without filling the form. From now on, the sender property looks filled in the template without any warning for later use. Please confirm if this is a bug on your side.
I'd be glad if you can speed up a little bit the guys from the support and link this thread,
Regards
Hello,
We just encountered the same issue with our account. Has the problem been since corrected? We have a lot of templates that have been corrupted.
Best regards
Ah ! Now we are legion 👯 .
Here is the reply I got from support after another ticket report
Thank you for reaching out.
Please note that Support is available only for the first 30 days on Free plan, which is not the case here. If you wish to have access to Support, please consider upgrading:
https://app.mailjet.com/subscription
We are aware of this issue, it usually happens when you're using an old template. The only solution for now is creating a new template or working through the API like explained by my colleague previously.
Wishing you a great day.
Regards, Alexandra | Mailjet by Pathwire
I believe the best you can do is pray that someone would eventually be smart enough to tackle this problem one day. So far, tickets have been automatically closed. Support is in denial ...
As a sidenote, it has nothing to do with "old templates" and my template would get corrupted again despite I fixed them through API.
Facing the same issue. So many month after first report and that bug is still not fixed? Is mailjet even maintained anymore?
Here're the detailed instructions on how get over it (given from support) It actually does work, which makes me think it doesn't have to see with the API. Once the template has been corrupted, even if the API cleans it, the corrupted values would come back if you hit save on the mailjet interface ...
What you can do in order to fix the template is to make a GET request on https://api.mailjet.com/v3/REST/template/$ID/detailcontent and copy the content from the response by removing the last line - "Sender": 000000 (which is actually causing the issue). Once done, you can created new template with this same content - POST with this payload on https://api.mailjet.com/v3/REST/template/$ID/detailcontent (by using the new template ID):
This simple shell does exactly that. GET the template, removing the sender header and POST it again.
#!/bin/bash
username=yourUsername
password=yourPassword
templateId=yourTemplateId
curl https://api.mailjet.com/v3/REST/template/$templateId/detailcontent -u $username:$password \
| jq 'del(.Data[0].Headers.Sender)' \
| jq -r '.Data[0]' \
| curl -X POST https://api.mailjet.com/v3/REST/template/$templateId/detailcontent -u $username:$password -H 'Content-Type: application/json' -d @-
Until the actual bug is fixed, I keep executing this script every time someone changes a template in my comp.
@maffelbaffel I can provide a patched version if necessary
@oromand If you could provide a fork or patch i'd take a look at it :+1:
@maffelbaffel The patched version is hosted here: https://github.com/oromand/mailjet-apiv3-dotnet/tree/fix-advanceErrorHandling. The whole point is to de-activate advanceErrorHandling while calling the API.
I see you already proposed a PR for this. Thank you for your effort!
Any news on this as the issue seems to still exist?
I have also encountered this exact same issue today. Editing and saving a template in MailJet's web interface causes it. Only solution I have found is to export and re-import to a new template. Will open a support ticket also.
The issue is still here. We are premium so we will contact the support but it's incredible that this issue is still there. Thanks for your solutions.
The issue has been merged, but most likely the nuget hasn't been republished ?
Le jeu. 19 mai 2022 à 15:56, AurelienDellac @.***> a écrit :
The issue is still here. We are premium so we will contact the support but it's amazing that this issue is still there. Thanks for your solutions.
— Reply to this email directly, view it on GitHub https://github.com/mailjet/mailjet-apiv3-dotnet/issues/69#issuecomment-1131725941, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZLBXKH2NGU3MWGK2XEDADVKZCCDANCNFSM4ZAJXQPA . You are receiving this because you were mentioned.Message ID: @.***>
-- Olivier ROMAND
Yes it hasn't been republished since a long time, thanks for your work, really
@oromand, @AurelienDellac just a quick follow-up question:
Is this a public nuget package you are refering to, or is this an internal mailjet package, that has now been updated? I'm asking because the same issue just happend a few days ago (might be before the 'republishing') with a template edited in the web interface. The template has not been altered by using the api via a nuget library. Only export + import resolved this.
My company wants to make sure this is fixed, as we have a lot of projects relying on mailjet and the number of broken templates in the past weeks has been somewhat anoying as you don't see on first glance that it fails because of some 'header'.
Hello @tkoenig89
We are referring to the "official" Mailjet.Api public nuget repository: https://www.nuget.org/packages/Mailjet.Api/ The version 2.0.2 has been published on 25/06/2021 PR has been accepted on 31/03/2022
The actual 2.0.2 Mailjet API nuget doesn't allow to bypass advandeErrorHandling. Thus you might encounter error on template not being valid while calling the API
If you do, you should consider using the actual source version (that include the PR) and publish your own nuget in your infrastructure.
@oromand thank you for the details!
So is there any fix planned in the (near) future to adress the templates getting corrupted in the first place, because i know of some code that might be hard to update for my company?
This is to see with the Mailjet team. Last return I had from (paid) support stated the problem was known but nothing was imagined to fix it.
See below
Our Technical Team got back to us and were able to figure out what is happening and why.
It seems that Passport is including sender object's ID due to the one pending save call.
Please make sure to hit the save button once the new sender address is created and publish the template afterwards. With this approach no Sender header with the object's ID will be added and you should have no issues using the AdvanceErrorHandling property.
Please note that this is not a bug, but the expected behavior - all started actions should be brought to an end to ensure the platform is functioning properly.
I just started to evaluate Mailjet as a potential service for us. Literally 4 hours of creating a bunch of templates and implemented this .NET SDK, I encountered this exact same error.
It's amazing to me that Mailjet has acknowledge their problem, they even have a fix for it waiting in a branch, but still haven't get their act together to help their paying customers after 2 years already. Amazing.
Anyways, I improved upon the bash sample above to iterate through a bunch of templates, since I had a lot of them.
#!/bin/bash
# Check if username and password are provided as input parameters
if [ $# -ne 2 ]; then
echo "Usage: $0 <username> <password>"
exit 1
fi
# Assign input parameters to variables
username=$1
password=$2
# Define the array of template IDs
templateIds=("templateId1" "templateId2" "templateId3")
# Loop over each template ID
for templateId in "${templateIds[@]}"
do
# Retrieve template details
response=$(curl "https://api.mailjet.com/v3/REST/template/$templateId/detailcontent" -u "$username:$password")
# Remove the Sender header using jq
updatedResponse=$(echo "$response" | jq 'del(.Data[0].Headers.Sender)')
# Update template details
updatedTemplate=$(echo "$updatedResponse" | jq -r '.Data[0]')
# Send the updated template details using POST request
curl -X POST "https://api.mailjet.com/v3/REST/template/$templateId/detailcontent" -u "$username:$password" -H 'Content-Type: application/json' -d "$updatedTemplate"
done
Save it as some bash file. e.g. fix-templates.sh
, amend the line with your templateIds.
Then call with your API Key and API secret; ./fix-templates.sh your-key your-secret
i found it juste unacceptable that this bug still open, created originally 2 years ago Thanks everybody for the workaround
From what I see this issue should have been already fixed. There was a code change on mailjet side to prevent the template from corrupting and the #82 PR was merged on 31/03/2022 and released on 7/5/2022 with the 3.0.0 version.
Do you set advanceErrorHandling to "false" and still have errors?
This is closed due to inactivity. Feel free to re-open in case of need.
@dmytrosvystun88 We seem to have this issue since 2023-07-28. Setting AdvanceErrorHandling
to false "fixes" the problem.
When I GET /detailcontent
, there's a suspicious Data[0].Headers.Sender: 23166
.
I'm also having this problem on 3.0.0. Same for me, disable AdvancedErrorHandling
"solved" the problem.
@dmytrosvystun88 should consider re-opening this one and either solve the problem in the SKD or provide better error messages.
Hello community,
I'm unable to send my templated email throught API. It's a simple template with no MJML. For some reason it fails with an error code
send-0019
and the following reasonWrong type for template header, expected type \"string\"
and a related errorsender
;Does any of you have any idea of the underlying problem ? And could point to some documentation that relates to this 0019 code ?
Thanks in advance.