Error sending notification email with large file attachment

[jlabs]

Describe the bug

Noticed a couple of email notifications have failed to send with the error (in the queue) Error: Unable to open path... on .../vendor\/symfony\/mime\/Part\/TextPart.php:156.

The standout difference between these notifications and others, is these have file attachments of 14mb. Others have a few hundred kb.

I've seen in the changelog from 2023 there was an issue sending large files, but the plugin is up to date.

Steps to reproduce

1. Create a notification that sends an attachment
2. Trigger the notification with a 14mb attachment

Form settings

• Multi-page form: No
• Submission Method: Page Reload
• Client-side Validation: Yes
• Custom Form Templates: No

Craft CMS version

5.8.19

Plugin version

3.1.5

Multi-site?

No

Additional context

No response

[jlabs]

Adding to this, I can see the files in the right place in Assets and I can open them. So they do exist. Other notifications send without issue too.

[engram-design]

Can you let me know what Mailer Craft is using? Some mailers do struggle sending large attachments.

Is this a user-uploaded file, or a static asset that you're attaching to the notification?

Finally, are you using Craft Cloud, or Servd, or similar? What's your volume filesystem look like (Local, S3, etc)? It may very well be struggling to find the file on your filesystem. Probably less likely given that you mention it works with small attachments, but worth a look if the error is about Unable to open path.

[jlabs]

The Craft report page shows @yii/symfonymailer - hope that is what you're after?

It's user uploaded files that aren't sending. Since I created the issue, more errors have appeared but now it appears not to matter on the filesize - even a few hundred kb are failing.

Using local storage on an EC2 instance. As far as I can tell all was working fine until a day or so before I raised the issue.
I've checked the file permissions of the uploaded files, and they match up with files that have sent OK.

[jlabs]

Managed to track down and (it appears) fix the issue. I added the @webRoot or @root to the base path in the filesystem, and the failed jobs sent ... well, 14 of the 16 failed have sent.

Not sure why this suddenly stopped working, but between 7:30pm and 10:15pm something stopped working as it had previously done.

[engram-design]

That's odd, but glad you got to the bottom of it!

[JulieVelghe]

Hi, I'm having the same problem on a site.
The size of the pdf attachment is only 255kb.
I have the following aliases in my general.php:
->aliases([
'@webroot' => dirname(DIR) . '/www',
'@SITE_URL' => App::env('SITE_URL'),
'@SITE_URL_CPT' => App::env('SITE_URL_CPT'),
'@SITE_ASSETS_PATH' => '@webroot/' . App::env('SITE_ASSETS_PATH'),
'@SITE_ASSETS_URL' => '/' . App::env('SITE_ASSETS_PATH'),
'@SITE_UPLOADS_PATH' => '@webroot/' . App::env('SITE_UPLOADS_PATH'),
'@SITE_UPLOADS_URL' => '/' . App::env('SITE_UPLOADS_PATH'),
])
and my filesystems has this for the attachments:
base-url: @SITE_UPLOADS_URL/attachments
base-path: $SITE_UPLOADS_PATH/attachments
local folder
and on the field itself I have selected the corresponding folder and added '/internship'

[engram-design]

I suppose it depends on how you run your queue, and if dirname(DIR) . '/www' isn't going to be resolved in the context of a queue job. I might suggest using an absolute path, at least just to test temporarily, which if that works, you can at least start to work backwards through your aliases and env variables to isolate the issue.