SlackBridge: Slack links <url|label> arrive as broken text "url|label" (no link, no preview)

Open
  • Is something wrong?
#43,583 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@jay23606 is already working on this.

Since Nov 7, 2026.

  • #43590 by @jay23606 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
typescript
Domain
backend

Research direction

Read apps/meteor/server/bridges/slack/RocketAdapter.ts, especially convertSlackMsgTxtToRocketTxtFormat around line 529, and compare its link handling with apps/meteor/server/lib/import/slack/SlackImporter.ts around lines 692–693. Check the existing bridge tests for this conversion, then verify that labeled Slack links render with the intended target and URL previews. An open linked pull request (#43590) already addresses this issue.

Written by the indexing model from the issue text.

Description

type: bug
Description:

SlackBridge does not convert Slack's link markup <url|label>. It only strips the angle brackets, so every link with a label arrives in Rocket.Chat as the literal text url|label. The message parser then treats the whole url|label string as one URL, so the link points to a wrong address and no URL preview is fetched.

Slack sends almost every link this way. Pasted links are usually <https://x.com/user/status/123|x.com/user/status/123>, and links with custom text are <https://example.com|some text>. On our workspace, where most messages come through SlackBridge, this affected about 15,000 bridged messages.

Steps to reproduce:
  1. Set up SlackBridge between a Slack workspace and Rocket.Chat.
  2. In a bridged Slack channel, post a link, e.g. https://x.com/user/status/123, or a link with custom text.
  3. Look at the bridged message in Rocket.Chat.
Expected behavior:
  • <https://x.com/user/status/123|x.com/user/status/123> becomes https://x.com/user/status/123: a clickable link that gets a preview.
  • <https://example.com|some text> becomes [some text](https://example.com).
Actual behavior:

The message text is https://x.com/user/status/123|x.com/user/status/123. The rendered link target is that whole string, and the message's urls contains it too, so the OEmbed lookup fails and no preview is shown.

Cause:

convertSlackMsgTxtToRocketTxtFormat in apps/meteor/server/bridges/slack/RocketAdapter.ts handles links with a single replace that keeps the |label part:

https://github.com/RocketChat/Rocket.Chat/blob/7625d7cc40f3320fad17b29236deed4530084cdb/apps/meteor/server/bridges/slack/RocketAdapter.ts#L529

slackMsgTxt = slackMsgTxt.replace(/<(http[s]?:[^>]*)>/g, '$1');

The Slack importer already handles the same markup correctly:

https://github.com/RocketChat/Rocket.Chat/blob/7625d7cc40f3320fad17b29236deed4530084cdb/apps/meteor/server/lib/import/slack/SlackImporter.ts#L692-L693

message = message.replace(/<(http[s]?:[^>|]*)>/g, '$1');
message = message.replace(/<(http[s]?:[^|]*)\|([^>]*)>/g, '[$2]($1)');

Using the importer's two replacements in the bridge would fix the broken links. Two details from patching this locally:

  • When the label is just the URL itself (Slack's usual case: the URL without scheme, or a shortened form with …), emitting the bare URL is better than [label](url). The parser autolinks a URL-looking label inside the markdown link, and the bare form keeps previews working.
  • The link replacement runs after &gt; is decoded (line 522), so a label containing > gets cut at that character. Converting links before the HTML entity decode avoids this.
Server Setup Information:
  • Version of Rocket.Chat Server: 8.9.1 (the same code is on develop at 7625d7c and in 9.0.0-rc.8)
  • License Type: Community
  • Number of Users: 38
  • Operating System: Linux (Ubuntu, kernel 6.8)
  • Deployment Method: docker
  • Number of Running Instances: 1
  • DB Replicaset Oplog: enabled (single-node replica set)
  • NodeJS Version: 24.22.1
  • MongoDB Version: 8.2.3
Client Setup Information
  • Desktop App or Browser Version: any (the stored message text is wrong, so it does not depend on the client)
  • Operating System: any
Additional context

We are running a locally patched image with this fix for now. I can open a PR if that would help.

Relevant logs:

No errors are logged; the conversion succeeds but produces the wrong text.

Dominant language
TypeScript
Stars
46.5k
Forks
14.1k
Avg merge
1d 21h
Merged PRs (30d)
381

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from RocketChat/Rocket.Chat

All issues in RocketChat/Rocket.Chat

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.