Closed lightbody closed 3 years ago
Since this change is additive it should be backwards-compatible, because it's not changing the existing structure of the payload. If your app assumes state will only be included in user-modified input blocks, you may want to verify how your app will respond to these changes.
I'm not sure it's immediately clear how (specifically) this change s causing the DESER to break. Is there any chance you have a clear understanding of that, and could drop a comment here on how the update breaks our current assumptions? If not we'll try and look into it but probably won't be able to fix before tomorrow (or the day after)
@szabowexler Just got a PR that should make it a bit more clear. Basically, the current code assumes StateActionValueIF
must have a non-null value returned by getBlockElementValue()
, but with this new change Slack will send back view states even if they have null values -- the examples I dropped in the testcase are real life ones we're seeing production right now.
Ok -- I'll review that right now and if it's good we'll cut an immediate release for you.
Changes merged, and release cut -- 1.12 should be out (see https://github.com/HubSpot/slack-client/releases/tag/slack-client-1.12).
It appears that this got released in the last few hours, and it's causing problems for parts of our application:
https://api.slack.com/changelog/2020-09-full-state-on-view-submisson-and-block-actions
Specifically, for us when we deserialize
SlackInteractiveCallback
and in particularBlockActions
, the new state data causes errors like this:I'm digging into a solution for this now, but I wanted to report it quickly so that others were aware. I suspect this may be affecting many users of this library today.