-
Notifications
You must be signed in to change notification settings - Fork 661
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
Modal responses for interactive-endpoint #909
Comments
I don't know the error details, and I don't know how I can fix it. It's so hopeless :( |
How about making sure if your Lambda function really received the requests by checking CloudWatch logs? I'm not sure what your situation is but there are several possible patterns:
|
@seratch, I mean when I make an action on Slack, Slack makes a request by using the interactive url I provided in the app's settings. My server receive the request from Slack (through interactive-endpoint) and send back to Slack the response like this:
With status code: 200 But I always receive:
But when I try to send the empty response with 200 OK, it close the modal view with no error |
I see. Does your modal have the restaurant-name? |
Just to be clear, your handler is returning the object you've shown above, right? And as @seratch mentioned, Let's also try to make sure it isn't timing out. Can you follow the instructions for debugging, and let us know what you see in the logs? |
@seratch My modal has a block with id
|
Here is my modal
|
This is the viewSubmission handler. I am using Express
|
Okay that’s great news. We’ve narrowed the problem down to usage with AWS Lambda. I haven’t used this package on Lambda before but you might find the information here helpful: #896 |
I'm having random lambda issues also. This is a very vague untested theory: I think the issue is thinking about the lambda as a server that can just keep running and processing async callbacks. I believe slack operates by both allowing responses to the initial request, but also posting of new messages to a specific As Lambda kills the running instance as soon as you return from it. there's no continuing on and then making another call to the Again this is just a hunch. |
Has anyone ever confirmed this? I think @dannyshaw is right. Anyone come up with a workaround? (FYI: I'm actually working in Python, but the behavior / error / cloud is the same... That's why I think it's Slack and and not a language or SDK per se.) |
+1 on the above, getting the following error
with a payload of
|
@lemonbakeoff The available solutions are:
const app = new App({
signingSecret: process.env.SLACK_SIGNING_SECRET,
token: process.env.SLACK_BOT_TOKEN,
processBeforeResponse: true,
});
app.command("/hellol", async ({ respond, ack }) => {
await respond("What's up?"); // posts a message using response_url
await ack(); // returns 200 OK after response_url call completion
}); @an-dev The valid one should be like this. Regarding the errors response, it is not supposed to be merged into the view. Your app sends only the following JSON data as an HTTP response to a {
"response_action": "errors",
"errors": {
"block_test": "lol"
}
} |
@seratch Thanks for your insight. I assumed the error response was to be merged with the existing modal template as the documentation isn't explicit about it being separate. |
@seratch regarding your Bolt example : app.command("/hellol", async ({ respond, ack }) => {
await respond("What's up?"); // posts a message using response_url
await ack(); // returns 200 OK after response_url call completion
}); Does it still mean the logic done before ack has to to be done under 3 seconds ? |
@gterras yes it does. It is a limitation of the current design but most use cases should be able to complete within that timeframe. Are you running into issues with it? |
I get occasional ack fails on Cloudrun which is expected to be sometimes slow (cold start, instance creation etc). This or any random network error can delay the response. This lead to a very unpredictable and confusing UX unfortunately (can click two times the same button, grey triangle popping etc) I fear that getting a response consistently under 3 seconds (actually less ?) is not possible for anyone who built an app following traditional Slack guidelines about events response, even if the processing logic is simple. There are too much factors and the risk is too high. The queue system seems the only reasonable things to do then, but what does |
FYI after discussion with my cloud team we concluded that by nature a Slack app is incompatible with FaaS core concepts (can't guarantee a cold start + request processing in less than 3s). Moving the app to AppEngine seems much more reasonable (same range of prices, container always up) and allow repositionning the ack at the top of listeners like a standard Slack app. |
@gterras IMO an always up solution is a better for slack apps, but we still want to support folks who want to use lambda (even though it has the limitations which you correctly mentioned). |
I'm sure the team already provided answers (at least responses) to all the questions and comments (the original question about modals and general questions about cold-starts) in this issue. Let me share some additional thoughts on the Just for your information, we started offering lazy listener functions in Bolt for Python as an experimental feature. To know what it is, refer to the document and an example code. The feature is yet another way to realize the concept I proposed at slackapi/bolt-js#361. It runs an asynchronous operation in another invocation of the same Lambda function with the same args ( We haven't decided to implement the same feature in Bolt for JS yet in the short term. The concept may have some conflict with Bolt for JS's fundamental design concept - a listener is a sequential chain of middleware. So, at this point, our general recommendation is to go with some solution that enables you to store messages in a queue (say, SQS) plus to run another function that subscribes the queue asynchronously. Thanks for writing in and sharing your thoughts here! If you would like to discuss the FaaS topic further, please feel free to create a discussion issue in bolt-js project like slackapi/bolt-js#361. |
Had the same issue with |
Not sure if people are still having this issue but we had it with Azure functions. Turns out we needed to pass the content-type as |
I had similar issues, the issue in my case was sending a 200 http but with some text. So for example I was sending |
Description
Describe your issue here.
What type of issue is this? (place an
x
in one of the[ ]
)Requirements (place an
x
in each of the[ ]
)I cannot use Interactive URL to response the form error for
view_submission
I write the api for interactive url in Lambda, then I set the interactive url and submit the form. I always receive this error on the view modal:
The response for
view_submission
event that is requested to my serverThe text was updated successfully, but these errors were encountered: