Discord watchtower / shoutrrr failing after 1.2.1

[tombomb]

Describe the bug
Just got the new update and now the app is failing to send discord messages via shoutrrr (This might belong in shoutrrr's github but I'm not sure where the underlining error is). Webhook url was working till latest update.

Image of it working before update

To Reproduce
Steps to reproduce the behavior:

1. Start container with WATCHTOWER_NOTIFICATION_URL
2. Get 400 error in logs

Expected behavior
Message to send

Screenshots
If applicable, add screenshots to help explain your problem.

Environment

• Platform
• Architecture
• Docker version

The section from my docker-compose stack pertaining to watchtower (redacted some of the webhook as to not give it out)

  watchtower:
    image: containrrr/watchtower:latest
    container_name: watchtower
    restart: unless-stopped
    networks:
      - default
      - socket_proxy
    depends_on:
      - socket-proxy
    volumes:
      - $DOCKERDIR/watchtower:/config
    environment:
      TZ: $TZ
      WATCHTOWER_CLEANUP: "true"
      WATCHTOWER_REMOVE_VOLUMES: "true"
      WATCHTOWER_INCLUDE_STOPPED: "true"
      WATCHTOWER_NO_STARTUP_MESSAGE: "false"
      WATCHTOWER_SCHEDULE: "0 30 12 * * *" # Everyday at 12:30 # "*/30 * * * *" # Every 10 mins
      WATCHTOWER_NOTIFICATIONS: shoutrrr
      WATCHTOWER_NOTIFICATION_URL: "discord://Q1p02j@7701"
      WATCHTOWER_NOTIFICATIONS_LEVEL: info
      DOCKER_HOST: tcp://socket-proxy:2375
      DOCKER_CONFIG: /config
      DOCKER_API_VERSION: "1.40"

Logs from running watchtower with the --debug option

time="2021-03-28T18:36:06-04:00" level=info msg="Watchtower v0.0.0-unknown\nUsing notifications: discord\nChecking all containers (except explicitly disabled with label)\nScheduling first run: 2021-03-29 12:30:00 -0400 EDT\nNote that the first check will be performed in 17 hours, 53 minutes, 53 seconds"


Failed to send notification via shoutrrr (url=discord://Q1p02jQGqJukmFo2ninybgxqIFUm8CADBmQIcMjgbiWCM_ZwqISIbEHmHqZvUGRDmOZV@770128369572118529):  failed to send discord notification: response status code 400 Bad Request

Additional context
Add any other context about the problem here.

[github-actions]

Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏

[piksel]

Add ?title=Watchtower to the end of your URL. I will open an issue for the cause of this in shoutrrr.

[tombomb]

Adding an update before I do the fix, it looks like normal updates are working. (except for the strangeness at the top of the embed).

There is a strange thing in the logs

it looks like that just lines like below are not sending.

yesterday at 9:33 PM time="2021-03-28T21:33:05-04:00" level=info msg="Watchtower v0.0.0-unknown\nUsing notifications: discord\nChecking all containers (except explicitly disabled with label)\nScheduling first run: 2021-03-29 12:30:00 -0400 EDT\nNote that the first check will be performed in 14 hours, 56 minutes, 54 seconds"

[piksel]

Hm, yeah, the messages are too long for the discord API (you are only allowed to send a maximum of 10 "items" per message, so this sends 9 lines (the blue ones) and one summary (the black one) which includes how many characters didn't fit.
You could add &splitLines=no to the URL to have every item be as large as the API allows instead. This should probably be the default, but this was used to mimic the style from the slack->discord bridge.

As for the startup-message, yeah, that should be sent as well. Not sure why that doesn't work.

Edit: The startup messages works for me, perhaps it hade something to do with the long ones? In any case, this is a comparsion of splitlines=yes (first one, default) and splitlines=no:

Edit 2: Oh, now I see what you meant. This was before adding the title argument. Yeah, since the "omitted" part is inside the meta-item (the black one) it doesn't cause the API to reject the message. It's only when there is no "omitted"-message and no title that you get the 400.

[tombomb]

I don't know enough about go to track it down to the root, but could it be related to the fact that the root.go uses log.<type> and the rest use log.<type>f (im also to lazy to set up a dev env to test)

watchtower/cmd/root.go

Line 249 in da56c21

log.Info("Watchtower ", version, "\n", notifs, "\n", filtering, "\n", schedMessage)

log.Info("Watchtower ", version, "\n", notifs, "\n", filtering, "\n", schedMessage)

watchtower/pkg/container/client.go

Line 232 in aa3ed88

log.Debugf("Starting container %s (%s)", name, creation.ID)

log.Debugf("Starting container %s (%s)", name, creation.ID)

both are using log "github.com/sirupsen/logrus"

tracking that back leads me to
https://github.com/sirupsen/logrus#fields
but I'm not sure where the formatting is set in the project, hopefully this will save some one some time tracking down the root cause of the issue.

[tombomb]

and yes, I'm seeing the same thing now too with the title fix workaround.

ill set the not sending of one line, as some times I have more then 10 updates at a time for the embeds.

[ksurl]

there is also no shutdown message anymore either. it used to say "Waiting for running update to be finished..." and then the startup message once it came up after restarting the container, docker daemon or the whole server.

[ksurl]

will the title fix remove it altogether? title is not required in discord embed api though this may just be a shoutrrr issue.

[piksel]

Yeah, it tries to send an empty embed, which the API rejects (containrrr/shoutrrr#150). Just an overlook when testing (as the title was a new feature, all my integration testing was done with a title, typical developer blind spot).

[tombomb]

Yeah, it tries to send an empty embed, which the API rejects (containrrr/shoutrrr#150). Just an overlook when testing (as the title was a new feature, all my integration testing was done with a title, typical developer blind spot).

Want me to close this ticket or leave it open till the new shoutrrr is in a live build

[simskij]

Added a close instruction to the PR, so this ticket will be automatically closed once the PR is merged. 👍🏼
We're expecting to include this in the v1.3.0 release.

[ghost]

To avoid important communication to get lost in a closed issues no one monitors, I'll go ahead and lock this issue. If you want to continue the discussion, please open a new issue. Thank you! 🙏🏼