Closed iwakiri0104 closed 2 years ago
Hi @iwakiri0104, thanks for asking the question! Perhaps, my reply here answered your question, right?
@iwakiri0104 Relying to https://github.com/slackapi/bolt-python/issues/693#issuecomment-1266428930
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 https://github.com/slackapi/bolt-python/issues/732 to provide an easier way to access the value in future versions. Until then, please check the Java SDK implementation (https://github.com/slackapi/java-slack-sdk/pull/677) and write your own global middleware to extract the retry properties from Socket Mode payload data.
@seratch Sorry for the misunderstanding. The reason for socket mode is for local testing, and the production environment is intended for FaaS (cloud function). What I really want to know is why the code here(#639 comment) does not allow me to see the contents of the request. I thought the above code would allow me to ignore the "X-Slack-Retry-Num", but it seems that I cannot even debug the contents of the request header in the first place.......
@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!! I will implement duplicate prevention by referring here. Thank you very much!
@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 ack()
, or am I missing something?
Shouldn't looking at X-Slack-Retry-Num
(and ignoring retry messages from Slack servers because it thinks the message has not been properly delivered so it keeps sending them) be considered "bad practice"?
@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