unfurl_links: false works with chat.postMessage but not with chat.scheduleMessage

vladislavrazumov commented 2 years ago

Description

Specifying unfurl_links: false seems not working for scheduleMessage method, but it works fine for postMessage. I send a couple of links, and a result message becomes a bit messy if all the links get previews so I would like to prevent automatic links unfurling. It's worth mentioning that I run scheduleMessage in a cron job, and send time varies from a couple of minutes to 12 hours but the result is always the same.

Here is a Slack doc about unfurling

What type of issue is this? (place an `x` in one of the `[ ]`)

[x] bug
[ ] enhancement (feature request)
[x] question
[ ] documentation related
[ ] example code related
[ ] testing related
[ ] discussion

Requirements (place an `x` in each of the `[ ]`)

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

package version: 3.8.1

node version: v14.17.1

OS version(s): MacOS 11.6, linux-based OS on remote server

Steps to reproduce:

Call chat.scheduleMessage method with unfurl_links: false param

Expected result:

The scheduled message will not be automatically unfurled after being sent to a user. The same way as if you specify unfurl_links: false for chat.postMessage

Actual result:

The scheduled message will be automatically unfurled after being sent to a user

Attachments:

The result message will be unfurled

      const response = await app.client.chat.scheduleMessage({
        channel: user.channel_id,
        post_at: timestamp,
        token: team.bot_token,
        blocks: [{
          type: 'section',
          text: {
            type: 'mrkdwn',
            text: `${welcomeMessage}\n${joinedSkills}`
          }
        }],
        text: welcomeMessage,
        unfurl_links: false,
        unfurl_media: false
      });

The result message will not be unfurled

      const response = await app.client.chat.postMessage({
        channel: user.channel_id,
        token: team.bot_token,
        blocks: [{
          type: 'section',
          text: {
            type: 'mrkdwn',
            text: `${welcomeMessage}\n${joinedSkills}`
          }
        }],
        text: welcomeMessage,
        unfurl_links: false,
        unfurl_media: false
      });

Interface of scheduleMessage arguments in typescript. It's the reason why I actually try to send this param

export interface ChatScheduleMessageArguments extends WebAPICallOptions, TokenOverridable {
    channel: string;
    text?: string;
    post_at: string | number;
    as_user?: boolean;
    attachments?: MessageAttachment[];
    blocks?: (KnownBlock | Block)[];
    link_names?: boolean;
    parse?: 'full' | 'none';
    reply_broadcast?: boolean;
    thread_ts?: string;
    unfurl_links?: boolean;
    unfurl_media?: boolean;
    team_id?: string;
}

srajiang commented 2 years ago

@vladislavrazumov - Thanks for providing your code here and for the helpful description of the behavior. If unfurl_links: false is not respected then it would be an issue server-side. API docs on the message say unfurl_links and unfurl_media should both be respected.

Let me try to reproduce this on my end - if I can I'll mark this as server-side and follow up with an internal team.

vladislavrazumov commented 2 years ago

@srajiang - Thanks for looking into this! Did you have a chance to reproduce the issue? I'll be happy to provide more details and try some other things if it helps

M1kep commented 2 years ago

I can also reproduce this:

import { Middleware, SlackEventMiddlewareArgs } from '@slack/bolt';
import moment from 'moment';

export const handleFurlTestMessage: Middleware<SlackEventMiddlewareArgs<'message'>> = async ({
    event,
    client,
}) => {
    const timeToSend = moment().add(10, 'seconds').format('X');

    const buildPayload = (url: string) => {
        return {
            channel: event.channel,
            blocks: [
                {
                    type: 'section',
                    text: {
                        type: 'mrkdwn',
                        text: `${url}`,
                    },
                },
            ],
            text: 'Test',
            unfurl_links: false,
            unfurl_media: false,
        };
    };

    await client.chat.postMessage({
        ...buildPayload('https://slack.com'),
    });

    await client.chat.scheduleMessage({
        ...buildPayload('https://api.slack.com'),
        post_at: timeToSend,
    });
};

CleanShot 2022-04-07 at 17 32 48

github-actions[bot] commented 2 years ago

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

M1kep commented 2 years ago

Not stale.

github-actions[bot] commented 2 years ago

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

richtu4n commented 2 years ago

I'm also having this issue. It would be great if Slack could provide a timeline for getting this fixed!

github-actions[bot] commented 2 years ago

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

hello-ashleyintech commented 2 years ago

Removing the auto-triage-stale label since this looks like it still needs some follow-up. @vladislavrazumov, @M1kep, @richtu4n - are you still experiencing this issue?

M1kep commented 2 years ago

@hello-ashleyintech I confirmed this is still reproducible with the same code I posted above

hello-ashleyintech commented 2 years ago

@M1kep thanks for the confirmation! I have raised this issue internally and will circle back once I receive an update.

github-actions[bot] commented 2 years ago

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

hello-ashleyintech commented 2 years ago

Dropping in an update here - this has been escalated internally and is on the responsible team's radar and roadmap as a fix! I will drop in any updates as they come in for this issue about the status of the fix - it may take some time since it was just added to their roadmap and they have a few other things lined up, so I'll be sure to be as communicative as possible when I hear anything and also make a note to follow up on this if I don't hear anything in a certain period of time. Thank you so much for reporting this and also for your patience! 🙌

github-actions[bot] commented 1 year ago

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.