Sending invoice email results in timeout

Self-Hosted | v5
1

My installation of Invoice Ninja (v5.1.34-C45, Ubuntu 20.04, Apache, MariaDB) fails to send invoice emails, whether invoked by the cron task (recursive, the status of invoices does change to ‘send’) or manually by clicking the corresponding button for a invoice on the GUI.

When using the manual send option, I receive the following error message: “TimeoutException after 0:00:30.000000: Future not completed”. Nothing in the Laravel log, nothing in the web server log and nothing in the system_logs database table about this error when it occurs (same result with APP_DEBUG set to true).

I temporarily switched the QUEUE_CONNECTION value to database, this fixed the ‘timeout’ exception visually but just resulted in the email tasks being stuck (other jobs were successfully processed, confirmed this as they were being removed from the jobs table, except the tasks responsible for sending the emails). Again, nothing in either of the 3 possible logging sources.

I have ‘triple’ checked that the email settings in the configuration file are valid and correct; tested with both SMTP and Sendmail. I’m not sure if this is a valid way of verifying if the email settings are indeed correct but the password reset feature on the login page does send me emails, with both mentioned mail drivers.

Another debug step I did was setting the various PHP parameters very high (timeout 500 seconds, 1gb memory limit), both PHP 7.4 and PHP 8.0. All with the same ‘timeout’ error as a result.

Love to hear if I’m missing something here, or if this could be some sort of bug.

1 Like
2

I found the cause; it was caused by the option under Email settings to attach PDF files. Disabling that has finally solved the issue for me.

1 Like
3

Obviously this leads to PDFs not being attached to the mail anymore so how can this be a solution?
That’s like going to the car service because your air condition smells and they tell you “So don’t switch it on anymore”

That’s a workaround, nothing more.

I got the same issue and I need to send Invoice-PDFs attached. It has always been this way in Invoiceninja 4 so why does this not work in IN5?
Why is there no useful error message? What do you mean by telling “Future not completed”?
And especially: Why is there no log entry in laravel.log about this error? I was searching for more than two days now!

4

@david any thoughts?

5

Fair point, you’re right.

6

Apologies for not following up on the matter and simply considering the issue solved by disabling the PDF email send feature. Below my additional findings after the original post.

The system log of a specific Client system log shows me this. I already verified that PHP runs under the same user all Invoice Ninja files are owned by and their permissions appear to be set correctly.Image

Due to privacy I cannot upload the full path as screenshot but it’s ‘https://<domain&extension>/storage/<64 character long string>/<40 character long string>/invoices/0007.pdf’

Like I explained in my original post, there is nothing about a permission exception (or any other warning or error) in the web server log or by Laravel in storage/logs/laravel.log.

7

Alsoa s a side note: I found it very unclear what to install and what to set in env-file to make sure that invoices never leave my system (as in pdf generation happens locally).

I installed phantomjs locally. Also I followed several sugestions for modifications to .env like setting PHANTOMJS_PDF_GENERATION=false or setting PHANTOMJS_BIN_PATH=/usr/bin/phantomjs as well as PHANTOMJS_KEY=’’

Of course I tried to send an invoice after every single change and it never worked in no constellation.

By the way: I get the same “unable tot open file for reading” issue.

Also… my v5 experience so far: V5 is a VERY bad joke

8

PHANTOMJS_PDF_GENERATION=false means your PDF generation happens locally.

Are you able to view the PDFs at all? It sounds like the local generation isn’t working at all.

9

Unfortunately, this issue is still present in the currently latest version of Invoice Ninja (v5.1.46-C45). Enabling the toggle to add the invoice as PDF to e-mails and than sending invoices (either manually or recursive) prevents them from being sent. Unlike with version v5.1.34-C45, the “…Future not completed” error message is no longer shown, the circle-like animation simple stops spinning and the Send button becomes selectable again. The “System failed to email invoice x” is also no longer logged whenever invoice sending fails.

PDF files are successfully being generated by PhantomJS (cloud); they can be viewed in the interface and their URL’s are written to Laravel’s log file. To again exclude a PhantomJS specific issue I tried using Invoice Ninja’s PDF generator as I do have a White Label license active on the install, this changed nothing and the same issue was still present.

While this issue obviously doesn’t break Invoice Ninja’s primary functionality I would definitely appreciate it if someone could dive into this issue further. My clients do not like not directly receiving their invoices as PDF attachments, and are unwilling to store the client interface credentials.

10

Bro I had a similar problem and it was because of my smtp server.

Check this in your settings: MAIL_ENCRYPTION=ssl or MAIL_ENCRYPTION=tls.

If you use incorrect one then IN tries protocol that smtp server rejects. So make sure you use correct one - best try both to be sure.

11

Appreciate the comment but this is not applicable to my setup; I am using Sendmail to send e-mails and have already confirmed email sending itself does work, just not with the PDF attachment option enabled.

12

This email issue still a problem for me in v5.1.53-C47. The problem was unchanged whether I used PhantomJS or generated locally. I was also able to “work around” it so to speak by disabling PDF attachments, but that pretty much defeats the purpose for me.

13

FWIW, this particular email/PDF problem remains for me in v5.1.60-C47. The info in the “System Logs” tab of the app is the same – “Unable to open file for reading” with the domain/storage//invoices/0036.pdf – and the app pops up an error message “TimeoutException after 0:00:30.000000: Future not completed”. Toggling the PDF attachments option off remains a workaround. PDF generation per se appears to work fine for me; I can see them in the browser, download them, and attach them to emails I create & send manually in my regular email program, just not get them attached to the app’s generated emails.

14

OK, this took me a while to find - but I think I got somewhere. I am using the Docker version of Invoice Ninja 5, but I realise this could be an issue elsewhere too.

The error Unable to open file for reading is located in the Swift-mailer, ByteStream file vendor/swiftmailer/swiftmailer/lib/classes/Swift/ByteStream/FileByteStream.php line 131 which is a call to $pointer = fopen($this->path, 'rb'); - Meaning the errors we are getting are due to the fopen() call from here.

As we are opening, in this case, an http*:// file I though I would try the same in a simple PHP file calling fopen() directly with the file.

This caused the error: PHP Warning: fopen(https://IN-hostname/storage/random-characters/invoices/Invoice-001.pdf): failed to open stream: Operation timed out in /var/www/app/test.php on line 3

I happened to also have my InvoiceNinja behind CloudFlare, which seems to recognise this action potential as a bot/hacker and just blocks the connection. I disabled the CloudFlare proxy option so it resolved the IP of the server directly, and immediately the test PHP file came back with a Resource identifier. The moment it did that, I tried to send the email again and it was successful.

Frustratingly, enabling the proxy on CloudFlare again didn’t make a difference, both the test PHP file and Invoice Ninja were able to connect, and everything continued to work again.

Not sure why it did this in the first place, as when I first ran this it seemed to be absolutely fine, just randomly one day it stopped.

If it helps, my mailer settings are set to send mail through Mailgun over TLS, but these settings, plus forcing PHP to somehow not time out with the fopen(), has fixed it for me.

MAIL_MAILER=smtp
MAIL_PORT=587
MAIL_ENCRYPTION='tls'
MAIL_HOST=smtp.mailgun.org
MAIL_USERNAME=invoiceninja@example.com
MAIL_FROM_NAME='Example Invoicing'
MAIL_FROM_ADDRESS='invoice@example.com'
MAIL_PASSWORD=super-secret-key

The PHP file I used for the test:

<?php
error_reporting(E_ALL);
$file = fopen('https://IN-hostname/storage/random-characters/invoices/Invoice-001.pdf', 'rb');
print $file;
?>

Also how I am set up for this:

|InvoiceNinja PHP-FPM Container| <-- |NGINX Proxy Container| <-- |CloudFlare|

Hoping this helps someone get to the bottom of this.

Colin

2 Likes
15

Just wanted to give another update, as before I mentioned that I switched CloudFlare back on and everything seemed to work – for a short while. Not only did I receive the same error as before after a few days, but I was also getting issues with the Client Portal (Token not valid), and issues downloading the invoice from the Client Portal too. This manifested itself in the error below:

[2021-05-17 08:18:37] production.ERROR: file_get_contents(https://IN-hostname/storage/random-characters/invoices/Invoice-001.pdf): failed to open stream: Operation timed out {"userId":75,"exception":"[object] (ErrorException(code: 0): file_get_contents(https://IN-hostname/storage/random-characters/invoices/Invoice-001.pdf)): failed to open stream: Operation timed out at /var/www/app/app/Http/Controllers/ClientPortal/InvoiceController.php:168)

Noted that it was the same error regarding time outs, I completely disabled CloudFlare and pushed everything directly to the Invoice Ninja NGINX Proxy container. I have not had any of the issues since.

Hopefully, this also helps other people track down the issues, but also where other times outs, including the original invoice email time out comes from.

TL;DR: Caching service (CloudFlare) in front of Invoice Ninja seems to cause issues with file streaming for both emails and the client portal due to their bot protection services.

2 Likes