Allow empty text parameter in chatPostMessage when using metadata without warnings

[heli-os]

When using chatPostMessage API with work objects pattern (metadata-only messages), the SDK generates warning logs requesting text parameter even though the message intentionally contains only metadata. This creates unnecessary noise in application logs.

ctx.client().chatPostMessage { req ->
    req
        .channel(ctx.requestUserId)
        .text("____") // unnecessary
        .metadataAsString(gson.toJson(metaData))
}

Current Behavior

When sending metadata-only messages using the work objects pattern, the SDK generates warnings even though text is intentionally omitted:

ctx.client().chatPostMessage { req ->
    req
        .channel(ctx.requestUserId)
        .metadataAsString(gson.toJson(metaData))
}

This produces warning logs like: "text parameter is missing" or similar, which clutters application logs when this pattern is used frequently.

Expected Behavior

The SDK should either:

1. Provide an explicit option to suppress text validation warnings when metadata is present
2. Automatically skip text validation warnings when metadata or metadataAsString is provided
3. Change the default behavior to not generate warnings for metadata-only messages

Proposed Solution

Add a parameter like suppressTextWarning or automatically detect when metadata is present and skip the text validation warning in that case.

Use Case

Work objects pattern is a valid Slack API pattern where messages contain only metadata for application-to-application communication without user-visible text. Generating warnings for this intentional usage creates log pollution and makes it harder to identify genuine issues.

Category (place an x in each of the [ ])

• bolt (Bolt for Java)
• bolt-{sub modules} (Bolt for Java - optional modules)
• slack-api-client (Slack API Clients)
• slack-api-model (Slack API Data Models)
• slack-api-*-kotlin-extension (Kotlin Extensions for Slack API Clients)
• slack-app-backend (The primitive layer of Bolt for Java)

Requirements

Please make sure if this topic is specific to this SDK. For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you agree to those rules.

[misscoded]

👋🏼 Hi @heli-os! Having spoken to the team, the consensus remains is that – like the warning advises – we recommend always using the text argument since it's used for system push notifications and assistive technology (screen readers).

Work objects pattern is a valid Slack API pattern where messages contain only metadata for application-to-application communication without user-visible text.

Could you provide us the specific case that you're referencing here? Are you describing a case where the message is literally blank, with no attachment having been unfurled? Might better help us see the exception required.

[heli-os]

👋🏼 Hi @heli-os! Having spoken to the team, the consensus remains is that – like the warning advises – we recommend always using the text argument since it's used for system push notifications and assistive technology (screen readers).

Work objects pattern is a valid Slack API pattern where messages contain only metadata for application-to-application communication without user-visible text.

Could you provide us the specific case that you're referencing here? Are you describing a case where the message is literally blank, with no attachment having been unfurled? Might better help us see the exception required.

Thanks for the feedback.

I understand the team's concern about accessibility with screen readers and push notifications. However, I'm facing a specific use case where the text argument conflicts with the Work Objects pattern.

My use case:

I'm implementing an approval workflow where users receive Work Objects for tasks requiring action (e.g., approval requests). Here's a simplified example:

val chatPostMessage = context.client().chatPostMessage { req ->
    req
        .channel(context.requestUserId)
        .metadataAsString(slackApiGsonSerializer.toJson(metaData))
}

(without text)

(with text, practice)

When I include the text argument, it creates visible text that doesn't align with the Work Objects UI pattern, resulting in a disjointed user experience.

Other Benchmarks:

1. The first image shows the Jira App sending notifications via DM without Work Objects.
2. The second image shows the Jira App handling Work Objects unfurling.

While unfurling URLs (as shown in the second image) feels natural, it's challenging to include a URL when sending an object via DM. Including any form of text in that context disrupts the visual experience. Even in the first image example, if we were to add Work Objects, the information would appear fragmented and scattered. This would undermine the core strength of Work Objects—their ability to present information in a structured and clear manner.

My question:

I completely respect the accessibility considerations for screen readers. However, I'm wondering if there could be alternative approaches to support accessibility without requiring visible text? For example:

1. Could Work Objects support an alt-like attribute that screen readers can access without displaying it as visible text?
2. Could there be a dedicated parameter (separate from text) specifically for screen reader/assistive technology that doesn't render in the UI?

This would allow developers to maintain the clean Work Objects pattern while still providing meaningful context for accessibility tools.

Would appreciate your thoughts on this or any guidance on handling this scenario within the current API design.

[misscoded]

Thank you for the great detail, @heli-os – it's extremely helpful for us to understand the issue you're facing! We're having an ongoing discussion about the best course of action, so kindly bear with us until next steps are determined. 🙇🏼‍♀️

[github-actions]

👋 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.