Giter Club home page Giter Club logo

Comments (4)

misscoded avatar misscoded commented on September 28, 2024

Hi @patrickshuff! I saw this was raised internally, and it looks like you may have received a resolution already, but I wanted to respond here and double-check – just in case anyone else runs into the same issue in the future. 🙂

As far as the thread I'm reading goes, it seems like the metadata was being returned as expected as seen in the payload screenshot provided above, but it just wasn't visible when inspecting the desktop client (as the client doesn't include metadata).

Is that correct? If I've gotten that wrong, please let me know, else we'll go ahead and close this issue if the issue is resolved.

from python-slack-sdk.

patrickshuff avatar patrickshuff commented on September 28, 2024

I'll try and summarize the underlying issue, and some potential options for getting around this, and then my opinions on what the slack engineering team should do:

The Root Problem

By default both on the RTM based message retrieval, and the API based message retrieval, any metadata EventPayload that is sent that does not explicitly have that event metadata structure added to the application manifest is stripped out. However on both endpoints it still passes the EventType through to the caller.

Recommended Solution (not verified)

The recommended fix from slack is to add metadata for the underlying event to the slack app manifest as defined here:
https://api.slack.com/automation/metadata-events

I have not verified this fix as I'm unable to do this at this time.

Potential workaround

For the API based conversation.history method there is a flag called include_all_metadata that is available in (thanks PR-1139) that you can pass that will have the server return all of the metadata. I have confirm this with the python and golang clients.

API Docs:
https://api.slack.com/methods/conversations.history#arg_include_all_metadata

For the RTM based message retrieval, which I am using for my use case, you are out of luck because there is no option to pass in a flag like this.

My opinions on what slack should do

This is a super confusing and painful developer experience to pass back the EventType but strip out the EventPayload. I spent an inordinate amount of time trying multiple SDKs on both the sending and receiving side to end up at the conclusion that the server must be stripping out the payload. The behavior that I'd rather see, in order of preference:

  1. Pass the entire EventType and EventPayload with the messages as they're being retrieved from both the API and RTM based endpoints regardless of a valid definition. The metadata was added to the API call for a reason
  2. If you decide that metadata event definition is required, it would be great if you had some way to give feedback to the developer that they're trying to send an metadata of EventType that is not registered and encourage them to do so instead of silently swallowing / discarding payload. e.g. on the server-side send back a HTTP400 with an error message that EventType is not configured.
  3. If you choose not to do no. 1 or no. 2, at least be consistent and strip both EventType and EventPayload so no metadata is returned so your developers aren't spending a ton of time trying to figure out why they're sending in the EventPayload incorrectly.

Lastly you should make sure that your HTTP API and RTM based APIs are equivalent. I was elated to know there was a workaround with include_all_metadata until I went back to the code realizing we were using the RTM interface to ingest messages to the bot.

Thanks for listening. I'll go ahead and close this out.

from python-slack-sdk.

github-actions avatar github-actions commented on September 28, 2024

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

from python-slack-sdk.

github-actions avatar github-actions commented on September 28, 2024

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.

from python-slack-sdk.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.