-
Notifications
You must be signed in to change notification settings - Fork 250
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
I would like to refer to X-Slack-Retry-Num. #731
Comments
Hi @iwakiri0104, thanks for asking the question! Perhaps, my reply here answered your question, right? |
@iwakiri0104 Relying to #693 (comment) It seems that you are using Socket Mode. In this case, the retry num value exists as "retry_attempt" in the body. I've created an issue for enhancement #732 to provide an easier way to access the value in future versions. Until then, please check the Java SDK implementation (slackapi/java-slack-sdk#677) and write your own global middleware to extract the retry properties from Socket Mode payload data. |
@seratch |
@iwakiri0104 Can you add the following code to your prod app? It should display all the request headers for you. @app.middleware
def log_request_headers(logger, request, next):
logger.info(request.headers)
next() |
@seratch Thanks to your help, I was able to confirm the "X-Slack-Retry-Num" in the log for the first time!! |
@iwakiri0104 Great to hear that! Let me close this issue now. |
Out of curiosity, aren't the retries being caused by the lack of calling Shouldn't looking at |
@eddyg Sorry for my belated response here. In general, you're right here. In most cases, we don't recommend ignoring retried event delivery. With that being said, we are aware of some situations like "Indeed, a Slack app's Request URL couldn't respond within 3 seconds but the main logic is successfully done on the server side. So, we don't want to repeat the logic again because running it again can result in duplicated outcomes (e.g., creating the same database record twice, posting the same message in a channel)". We call it a kind of workaround but as long as a developer does understand the downside of the approach, it can be okay in the real world. |
I want to deploy a Slack bolt using Cloud Function, but since I can't use lazy listener, I use Thread for parallel processing. When I deploy to Cloud Function with the following code, I get duplicate messages the first time. After that, it only needs to be done once. However, after some time passes, duplicate messages are sent again.
Therefore, I would like to implement a process that only returns a response if there is an X-Slack-Retry-Num in the header, but I do not know how to get the header.
I implemented the following code in Python this way,
Ended with an error result.
Please let me know if there is a better solution.
### This is my code:
The
slack_bolt
versionslack-bolt==1.14.3
slack-sdk==3.18.3
Python runtime version
Python 3.9.12
Expected result:
I want to prevent duplicate messages.
Actual result:
Duplicate messages more than three times
The text was updated successfully, but these errors were encountered: