-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: Improvements around app.message(...) #465
Comments
This is a well thought out and thorough proposal! Question: In Bolt for Java, would it be possible to use constraints properties to vary the type of arguments passed to a listener? This is how we've been able to solve this problem in Bolt for JavaScript in the |
Yes, it's possible and even is necessary for Bolt for Java apps. Developers are not allowed to make the type ambiguous. Here is a simple example demonstrating how to use it: |
Thanks for writing this out @seratch! So the proposal is to have Questions:
|
Good point. Yes, it is a breaking change. So, it may be better to consider a bit careful transition like providing an option to change the behavior in the next minor release, and then changing the default in the next major release.
I think |
This was a wrong assumption. If other bot users in the same workspace are still classic apps, they may generate message events with bot_message subtype. As of version 1.4.4, bolt-python handles only non-subtyped and "bot_message" subtype events by |
Hey so if I am building a slack app currently and receiving events via the slack events web api should I handle the cases with subtype as |
@batflarrow As I mentioned above, both no subtype and "bot_message" subtype patterns can still co-exist. If other bots in your workspace are still based on legacy permission model (we call it "classic" app), their message events don't have the bot_message subtype. |
It's the other way round right "classic" app's messages with have a sub_type as bot_message and not the new apps this was what you mentioned above in this comment. |
Also is there a list of these "classic" apps, how can I test my code for cases with sub_type as bot_message or is there a way just to know the payload in cases where the events will be sub_typed as bot_message |
If you don't have so many apps in your workspace, it may not be so hard to review the scopes of the apps listed at https://slack.com/apps/manage . However, I think that your goal is to safely respond to all new messages. If so, all you need to do are:
|
yeah but I am building a slack app myself for people to use and they can have any apps installed on their systems themselves so I will have to handle the cases with the "bot_message" subtype. It would be great if I could find a event with the sub_type as bot_message but anyways I'll look for it .The issue is the I need the |
Proposal
As described at #463,
app.message(...)
's behavior with the latest payloads is not intuitive for developers. It's surprising for developers to receive more events than the number of messages in a channel.I propose to change the behavior to receive only
message
typed events that don't have a subtype. With this, Bolt apps can receive only events telling the arrival of new messages.Also. there is one additional thing we may need to care about in the future. As far as I know, the server-side no longer sends
bot_message
subtyped events. Instead, it sends no-subtype events withbot_id
andbot_profile
properties. If the server-side gets back to the previous behavior in the future, we may need to addbot_message
events as well.For reference: @aoberoi 's slackapi/hubot-slack#589
References
The list of sutyped
message
eventsThere are a number of subtype events for messages. Some of them may have a quite different data structure compared with
message
typed events without a subtype.bot_message
ekm_access_denied
me_message
message_changed
message_deleted
message_replied
reply_broadcast
thread_broadcast
Bolt for Java's approach
Bolt for Java's
app.message
listeners receive onlymessage
events that don't have a subtype.https://github.com/slackapi/java-slack-sdk/blob/v1.0.3/bolt/src/main/java/com/slack/api/bolt/App.java#L509-L526
There are two reasons for that. It's technically impossible to include other events due to the Reason 2.
text
MessageEvent
class in this line is a representation ofmessage
typed event without any subtype. Other events with subtype look like this.Regarding
bot_message
events, Bolt doesn't invoke listeners given toapp.message
due to the difference in the structure of payloads. If the server-side is changed in the future, Bolt for Java may need to consider introducing a new routing method.What type of issue is this? (place an
x
in one of the[ ]
)Requirements (place an
x
in each of the[ ]
)The text was updated successfully, but these errors were encountered: