Mattermost-server: slack-compatibility-layer seems to break results of MM-only integration

[someone-somenet-org]

Our haskell-bot produces weird output, as it would change the order of the input lines and stuff like that.

We strongly suspect the weird behaviour is introduced by the slack-compatability-layer which mattermost uses by default and which we cannot find a way to disable.

Summary

Slack-compatibility seems to break results of /command-integrations. (not tested with webhooks)

Steps to reproduce

1: Create a command (/haskell) which posts to a local integration's webserver.
2: let integration's webserver return for example
{ "text": "**Input**\n```haskell\nlet\n\nf1 = [ 3 | a <- [1]]\nf2 = [ 4 | b <- [2]]\nf3 = \\p -> 5\n\nin 1\n```\n\n**Output**\n```haskell\n1\n```", "username": "lambdabot", "response_type": "in_channel" }
3: get shown
``````
Input

let
f1 = [ 3 | a [ b <- [2]]
f3 = \p -](- [1]]
f2 = [ 4 ) 5
in 1

Output

1

instead of
Input

let
f1 = [ 3 | a <- [1]]
f2 = [ 4 | b <- [2]]
f3 = \p -> 5
in 1

Output

1

``````
Note the swapped lines and changed brackets.

Our minimal issue-triggering input seems to be

• <a|b< -> output [b<
• <a|b> -> output [b](a)

Which seem to be a direct translation attempts from the slack-compatability-layer.

Expected behavior

MM not changing integration's contents, if not desired.

Possible fixes

Add a way to disable the slack-compatibility-layer server-wide or on a command/integration basis.

[lieut-data]

@somenet, I'm having trouble reproducing this. If I create an incoming webhook, for example:

> cat ~/tmp/haskell
{
  "text": "**Input**\n```haskell\nlet\n\nf1 = [ 3 | a <- [1]]\nf2 = [ 4 | b <- [2]]\nf3 = \\p -> 5\n\nin 1\n```\n\n**Output**\n```haskell\n1\n```",
  "username": "lambdabot",
  "response_type": "in_channel"
}
> cat ~/tmp/haskell | http POST http://localhost:8065/hooks/gfjemar9qjf7tmmts1z6bnrdho
HTTP/1.1 200 OK
Content-Length: 2
Content-Type: text/plain
Date: Thu, 10 Oct 2019 01:18:24 GMT
X-Request-Id: pinscq4b6iyd7cosq1pohxbkby
X-Version-Id: 5.18.0.dev.0ea6f9abab5ca3716d65667bdc351ed4.false

ok

I appear to get the desired behaviour:

Can you help provide more details on how we can reproduce?

[fendor]

Indeed, with webhooks this behaviour is not reproducible.
So maybe this only happens with slash commands?

[lieut-data]

Ah, good catch @fendor -- I can indeed reproduce this with a slash command. I didn't read the original post carefully enough.

The offending line seems to be: https://github.com/mattermost/mattermost-server/blob/eae1acef5f5886566455282cff85119c8451d911/app/command.go#L43

Without it, the message posts as expected. Let me look into this a bit more.

[lieut-data]

I've filed a Jira ticket to mirror this one: https://mattermost.atlassian.net/browse/MM-19540, and will have our Toolkit team investigate. I agree we should make the Slack compatibility customizable in some fashion as you suggest.

[someone-somenet-org]

I just run into this issue again. This time when responding to interactive message buttons.

Is there any ETA on this?

In jira this gets only delayed all the time. Therefore I would suggest to add a parameter "ignore_slack":"true" so that an integration could signal that it doesn't care about slack compatibility.

If we were not running an enterprise instance, I would just patch that line out and recompile and be fine, but this is unfortunately not an option.

[lieut-data]

Apologies, @somenet, we haven't taken a look at that in the core team yet. I like your thinking on the topic, though, and can't imagine a better solution given the need to retain backwards compatibility.

If I turn this into a help wanted ticket, would you be open to help making exactly that change? Happy to provide whatever support is needed on our end :)

[someone-somenet-org]

@lieut-data Ill look into it :)

[someone-somenet-org]

Its fix'd. Nearly everything needed was already there. PR incoming tomorrow.

Command-Response without and with "skip_slack_parsing":"true"

[lieut-data]

Terrific! Thanks, @somenet :)