Issue with taiga-async when trying to send emails

Hey,

I am trying to get Taiga CE to run locally using Docker.
Everything starts up, and I can do the most important stuff i. e. project management.

However, when I try to send an email notification (using default mail or sendtestemail), I don’t receive anything plus the logs seem to indicate something’s not working properly.

taiga-gateway | 172.18.0.3 - - [09/Aug/2023:16:07:17 +0000] "POST /api/v1/contact HTTP/1.1" 201 97 "https://sub.domain.tld/project/the-project/timeline"
taiga-async   | [2023-08-09 16:07:17,175: INFO/MainProcess] Task taiga.projects.contact.services.send_contact_email[uuidv4 #1] received
taiga-async   | [2023-08-09 16:08:26,384: INFO/Beat] Scheduler: Sending due task send-bulk-emails (taiga.projects.notifications.tasks.send_bulk_email)
taiga-async   | [2023-08-09 16:08:26,392: INFO/MainProcess] Task taiga.projects.notifications.tasks.send_bulk_email[uuidv4 #2] received

and it keeps on looping, and I never receive the notification/email :cry:

I went into the container and checked that my SMTP was working fine using telnet.
Here is my SMTP config:

EMAIL_BACKEND=smtp 
EMAIL_HOST=172.27.0.3  # Docker MailServer
EMAIL_PORT=25
EMAIL_HOST_USER=
EMAIL_HOST_PASSWORD=
EMAIL_DEFAULT_FROM=noreply@domain.tld

EMAIL_USE_TLS=False
EMAIL_USE_SSL=False

I am using Docker Mail Server, which runs Postfix and some other stuff. It only allows email to be sent from docker subnets and localhost, hence I did not bother setting up TLS/SSL nor auth.

Last thing that may be a cause of the issue, I am running Taiga behind my own nginx proxy, configured to proxy using taiga-gateway container.

Finally, here is the complete docker config.

version: "3.5"

x-environment:
  &default-back-environment
  # All the default stuff here

x-volumes:
  &default-back-volumes
  - ./taiga-static-data:/taiga-back/static
  - ./taiga-media-data:/taiga-back/media

services:
  taiga-db:
    container_name: taiga-db
    image: postgres:12.3
    environment:
      POSTGRES_DB: "taiga"
      POSTGRES_USER: "${POSTGRES_USER}"
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 2s
      timeout: 15s
      retries: 5
      start_period: 3s
    volumes:
      - ./taiga-db-data:/var/lib/postgresql/data
    networks:
      - taiga

  taiga-back:
    container_name: taiga-back
    image: taigaio/taiga-back:latest
    environment: *default-back-environment
    volumes: *default-back-volumes
    networks:
      - taiga
      - dms # Docker Mail Server's external net
    depends_on:
      taiga-db:
        condition: service_healthy
      taiga-events-rabbitmq:
        condition: service_started
      taiga-async-rabbitmq:
        condition: service_started

  taiga-async:
    container_name: taiga-async
    image: taigaio/taiga-back:latest
    entrypoint: ["/taiga-back/docker/async_entrypoint.sh"]
    environment: *default-back-environment
    volumes: *default-back-volumes
    networks:
      - taiga
      - dms
    depends_on:
      taiga-db:
        condition: service_healthy
      taiga-events-rabbitmq:
        condition: service_started
      taiga-async-rabbitmq:
        condition: service_started

  taiga-async-rabbitmq:
    container_name: taiga-async-rabbitmq
    image: rabbitmq:3.8-management-alpine
    environment:
      RABBITMQ_ERLANG_COOKIE: "${RABBITMQ_ERLANG_COOKIE}"
      RABBITMQ_DEFAULT_USER: "${RABBITMQ_USER}"
      RABBITMQ_DEFAULT_PASS: "${RABBITMQ_PASS}"
      RABBITMQ_DEFAULT_VHOST: "${RABBITMQ_VHOST}"
    hostname: "taiga-async-rabbitmq"
    volumes:
      - ./taiga-async-rabbitmq-data:/var/lib/rabbitmq
    networks:
      - taiga

  taiga-front:
    container_name: taiga-front
    image: taigaio/taiga-front:latest
    environment:
      TAIGA_URL: "${TAIGA_SCHEME}://${TAIGA_DOMAIN}"
      TAIGA_WEBSOCKETS_URL: "${WEBSOCKETS_SCHEME}://${TAIGA_DOMAIN}"
      TAIGA_SUBPATH: "${SUBPATH}"
    networks:
      - taiga

  taiga-events:
    container_name: taiga-events
    image: taigaio/taiga-events:latest
    environment:
      RABBITMQ_USER: "${RABBITMQ_USER}"
      RABBITMQ_PASS: "${RABBITMQ_PASS}"
      TAIGA_SECRET_KEY: "${SECRET_KEY}"
    networks:
      - taiga
      - dms
    depends_on:
      taiga-events-rabbitmq:
        condition: service_started

  taiga-events-rabbitmq:
    container_name: taiga-events-rabbitmq
    image: rabbitmq:3.8-management-alpine
    environment:
      RABBITMQ_ERLANG_COOKIE: "${RABBITMQ_ERLANG_COOKIE}"
      RABBITMQ_DEFAULT_USER: "${RABBITMQ_USER}"
      RABBITMQ_DEFAULT_PASS: "${RABBITMQ_PASS}"
      RABBITMQ_DEFAULT_VHOST: "${RABBITMQ_VHOST}"
    hostname: "taiga-events-rabbitmq"
    volumes:
      - ./taiga-events-rabbitmq-data:/var/lib/rabbitmq
    networks:
      - taiga

  taiga-protected:
    container_name: taiga-protected
    image: taigaio/taiga-protected:latest
    environment:
      MAX_AGE: "${ATTACHMENTS_MAX_AGE}"
      SECRET_KEY: "${SECRET_KEY}"
    networks:
      - taiga

  taiga-gateway:
    container_name: taiga-gateway
    image: nginx:1.19-alpine
    volumes:
      - ./taiga-gateway/taiga.conf:/etc/nginx/conf.d/default.conf
      - ./taiga-static-data:/taiga/static
      - ./taiga-media-data:/taiga/media
    networks:
      - taiga
      - proxy
    depends_on:
      - taiga-front
      - taiga-back
      - taiga-events

networks:
  taiga:
    name: taiga
  proxy: # nginx reverse proxy's net
    name: proxy
    external: true
  dms: # docker mail server's net
    name: dms
    external: true

Hi, @Daerendor

try run the test emails command (this send a lot of sample email), maybe give you more information about the problems with the connection with the smtp server.

./taiga-manage.sh test_emails your_peronal_email_address@email.com

Regards

Just did that and got the following error.

Traceback (most recent call last):
  File "/taiga-back/manage.py", line 17, in <module>
    execute_from_command_line(sys.argv)
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/taiga-back/taiga/base/management/commands/test_emails.py", line 52, in handle
    membership.invited_by = get_user_model().objects.all().order_by("?").first()
    ^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'invited_by'

Also,
I got another error when trying to add a new user to a project using an email address. The error was saying that User and Password are required for SMTP Auth. Is there a way to disable this requirement?

Well, the first error is because the sampledata needs to be loaded to launch the test. However some email should have been sent.

The second error you mention may be the key. Taiga does not need you to configure username or password to connect to the SMTP server. I think that error is what your smtp server returns to Taiga when it tries to connect with the credentials you have set up.

I don’t know much about docker-mailserver but I see that the credentials are stored in config/postfix-accounts.cf. If you don’t know your credentials, you can define a new credentials doing this (according to an issue in github ;-))

cd docker-mailserver/
./setup.sh email add foo@example.com mysecretpassword
cat config/postfix-accounts.cf     # This common show the user and the hashed password

Alright, so I’ve spent the past few days setting up my mailing agent correctly. FYI I was using weird workarounds that caused some bugs, fixed that.

However, my issue isn’t over yet.
I’m trying to test emails again using “test_emails”, and I get this now.

Traceback (most recent call last):
  File "/taiga-back/manage.py", line 17, in <module>
    execute_from_command_line(sys.argv)
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/venv/lib/python3.11/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/taiga-back/taiga/base/management/commands/test_emails.py", line 52, in handle
    membership.invited_by = get_user_model().objects.all().order_by("?").first()
    ^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'invited_by'

Also, when I try to invite someone to a project, I get this in taiga-async:

[Date] [1] [CRITICAL] WORKER TIMEOUT (pid:30)
[Date] [52] [INFO] Booting worker with pid: 52

Hi @Daerendor ,

As I told you in my previous comment, the first error is because the sampledata needs to be loaded to launch the test. The sampledata is a command that generates users, projects and other elements in the database to be able to test the platform. The command is ./taiga-manage.sh sample_data, But keep in mind that they will generate sample data that you will have to delete later. However some email should have been sent even with this error.

The second error, [Date] [1] [CRITICAL] WORKER TIMEOUT (pid:30), should be because there is some error with the connection between taiga-back and taiga-async or maybe the taiga-async-rabbitmq instance is not working fine. You can review the logs of taiga-async and taiga-async-rabbitmq to see if they have started correctly. And you can restore the services by deleting them completely:

docker compose rm -sf taiga-async-rabbitmq
docker volume rm -f taiga-docker_taiga-async-rabbitmq-data

Thanks for your help. I will try and recreate the container from scratch/using the default compose file, and I will gradually make changes to see where I made a mistake (must be hostnames or smth similair).

1 Like

Hey,
I made sure to follow your hints before replying again about my issue.

First off, I created a new project after recreating everything from scratch, using the default compose/env files (I just changed container names and volume names, nothing fancy).
In the project I tried to invite a new member. I got the following in the console:


Might be nothing useful - seems to be the direct consequence of email not being sent correctly, but still sharing.

Then, I tried to execute sendtestemail again, just to check my new config. Nothing came in my inbox, even though “If you’re reading this, it was successful.” (: .
I also tried test_emails, and nothing went wrong.

So since my email setup seemed right, I did the last thing you advised me to do, i.e. checking docker logs (no issues), and finally removed the container and volumes.
I tried to send an invite, there was an issue connecting to taiga-async (who could have guessed). I then composed down and up again. Again, worker dies and reboots.
The only thing I can think of is related to proxy configuration. Plus I’m running behind a nginx reverse proxy which routes everything from taiga.domain.tld to taiga’s gateway.

I cannot think of anything else sadly.

Edit (was not posted but edit for me): the console shows that something’s trying to reach /events using wss, but the endpoint seems to be unreachable. That comforts my idead that it’s a proxy issue.

Edit 2: it IS a reverse proxy issue. I had to declare explicitly the custom locations in my proxy. I will now get rid of the embedded gateway, since it is not useful for me.

I’m glad it got fixed.

From the screenshot you show, just tell you that the 404 you get when accessing urls like */user-storage* are not errors, it is an expected behavior (and will happen more times throughout the platform).

That 502 seems to be what you say, a problem in the proxy pass.

For emails, another recommendation would have been to configure console to check in the logs that the email is generated without issue. In this way we would have confirmed that the problem is in the configuration of credentials to send emails from the platform to the smtp server.

Best regards.

Hey, about those 404s,

In fact I was making things a bit overly complicated. Removing the integrated gateway was not a good idea, because it makes things harder to manage.

I stumbled upon this comment here that said what I needed to do.

So for anyone reading this,

Step 1: Add your reverse proxy’s network to taiga-events’ networks

Step 2 : Don’t change anything in the gateway config (:

Step 3 : In NPM or any nginx reverse proxy, set two locations,

  • location / proxying to taiga-gateway port 80
  • location /events proxying to taiga-events/events/ port 8888

The trailing slash is there because NPM is weird.

Thanks, @david.barragan <3

NB: it may be useful to mention this in the “configure the proxy” section of the documentation.

1 Like

Yes, @Daerendor, we have a section here (Taiga 30min Setup) with an example on how to configure your own proxy (to the taiga gateway) so you can do what you want (secure with ssl certificates for example) but it doesn’t seem to be very clear, sorry.

We definitely need to improve this part of the documentation.