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
Inconsistent SlackObjectFormationError raising when empty text is provided. #1267
Comments
Hi, @kezabelle! Thanks so much for writing in! I took a look at the issue you described and agree that the difference in behavior can feel confusing. I'll be reaching out to a member of my team to get additional context on whether this behavior is expected or not and to look into what can be done here. I'll add any updates or additional findings here within the next day or so! |
Hi, @kezabelle! I chatted with a member of my team about this and we identified that adding in error handling for the described scenario could potentially cause breaking changes. Because of this, and also since there's still some SDK side validation for the scenario, we are hesitant to add in additional error handling here and alter the behavior of |
Hey, @hello-ashleyintech, thanks for taking the time to look into it. I appreciate it. Apologies for the delay in responding, I've been away. I'll preface everything hereafter with a degree of uncertainty, as I've primarily been branching out to using
Would you be able to describe in what scenarios it could produce valid output which Slack would actually consume? On that set of assumptions (which may be incorrect!), what breaking changes would this cause that aren't already broken? Any tightening of validation is always a backwards incompatible, breaking change in potentia, but this would seem to me (naively) to simply be bringing the API in-line with the schema.
Again, unfamiliar with the rest of the modules, but where might I expect to find this? I'm presuming SDK here means
There error message itself is fine, honestly. It's the complete absence of an error in another scenario which amounts to the same error, that I'm finding fault with. Were there no validation, I'd just chalk it up to something to deal with myself, but as there is some I now need to mentally keep track of which validations the In case it's easier to read the (pseudo-)code I'd roughly be (naively) proposing, off the to of my head the validation would be something like the below, give or take personal proclivities for type-checking or shape-checking and stylistic choices for brevity etc:
|
@kezabelle Thanks for the reply! 🙌
If any valid string that is not empty is passed in to the
This is a great question! On receiving this issue, I had actually tried to implement error handling for this locally in a similar place where the Basically, with my tested implementation (similar to what @/eddyg had suggested), it seemed like throwing an error in that particular location would end up altering the behavior of
Within the Block Kit, there is some validation. Here is an example of a Let me know if you have any additional questions here! This is helpful feedback and definitely something we can consider a better pathway for in the future, especially if more folks run into similar issues with this. 🙌 |
Given the following:
This is all correct enough and good enough. What's happening behind the scenes appears to be that
TextObject.parse
is used and does a truthy test on the incomingtext
, and returnsNone
as opposed to an empty string.Where that begins to go wrong, is here:
Slack will reject that as erroneous. If it's sent back as part of the acknowledgement response as a
response_action
we won't necessarily see (receive) an error related to failing to parse the JSON schema. Slack's block kit builder says of it:Missing required field: text
Category
Desired outcome
Ideally, I'd like to be able to trust (more) that the validation present in
slack_sdk
is going to raise on invalid configurations early, and consistently -- that is, where possible I'd like to assume that putting together something "empty" even if I've opted to use the classes instead of an equivalent base type (str
,dict
) should raise.The text was updated successfully, but these errors were encountered: