Mattermost not working anymore

[N-Schaef]

Since a recent update in the Mattermost server, notifications do not work anymore.
I don't know which version exactly broke this, but we updated from 5.19 -> 5.22.

I also think I found the issue.
Since recently the parsing of the incoming webhook slightly changed.
Mattermost will now throw an api.webhook.incoming.error when the "Content-Type" header can't be parsed. Mattermost Code

This plugin uses the slacker library to communicate with slack/mattermost.
But sadly this library does not set the content header.
Slacker Incoming webhook post

Now the nice fix would of course be that this library is fixed and then the changes are pulled downstream. But this means that this plugin won't work with mattermost for the foreseeable future.

Anything else that could be done?

[fraschetti]

Hi @N-Schaef

I'm working on buttoning up a number of changes for Slack connectivity but will try to circle back to this before pushing a new release to see if I can find a quick fix. If I can't find a quick workaround, I'll likely address this after the next release so I can give it the attention it deserves.

Stay tuned.

[fraschetti]

Hi @N-Schaef

I did carve out some time to look into this issue but unfortuantely the Mattermost server I was previously using for testing was decomissioned (the team switched to Discord) and I haven't had the time to setup a Mattermost system of my own.
I'll likely circle back to this issue once I find the time to setup a Mattermost server of my own or find a publically hosted Mattermost server w/ a webhook that I can test against. Mattermost themselves host a few servers but unfortunately none of them provide a suitable environment to test against.

[mortanius-1]

Hi @fraschetti I too have this issue and I happen to be running Mattermost Version: 5.23.0. I could even let you test against my own instance if you required it?

The error triggered in Mattermost whenever Octoslack attempts to send a message is as follows:

Could not decode the multipart payload of incoming webhook.

[mortanius-1]

The fix should be made on the Slacker side so I expanded on @fraschetti related issue on the Slacker issue tracker and suggested a change: os/slacker#168 (comment)

[mortanius-1]

For anyone just looking to get this working whilst waiting for a fix, on your Octoprint instance login via SSH.

Hackish fix, direct edit to Slacker:

sudo nano /home/pi/oprint/lib/python2.7/site-packages/slacker/__init__.py

Search for line 1182 and add the headers attributes to the payload:

return requests.post(self.url, data=json.dumps(data),
                         timeout=self.timeout, proxies=self.proxies,
                         headers={'content-type': 'application/json'})

Or something a little more robust @fraschetti, you could monkey patch the function (I'm using this currently and it works well). In file Octoslack/octoprint_Octoslack/init.py some where near the top say line 55 add the code below.

def post(self, data):
    """
    Posts message with payload formatted in accordance with
    this documentation https://api.slack.com/incoming-webhooks
    """
    if not self.url:
        raise Error('URL for incoming webhook is undefined')

    return requests.post(self.url, data=json.dumps(data),
                         timeout=self.timeout, proxies=self.proxies,
                         headers={'content-type': 'application/json'})


# Patch up webhook class
IncomingWebhook.post = post

[mortanius-1]

Hey @N-Schaef Mattermost have release a new version: 5.23.1 that fixes this issue.

Detail:
Modified the mime check, such that we now require Content-Type to be set in the request header.
This change was unintentional and led to breaking changes.

See issue: https://mattermost.atlassian.net/plugins/servlet/mobile?originPath=%2Fbrowse%2FMM-25677#issue/MM-25677