How to Prevent Retry Request

[jayyhkwon]

(Describe your issue and goal here)

The Slack SDK version

[INFO] +- com.slack.api:bolt-servlet:jar:1.4.0:compile
[INFO] | +- com.slack.api:slack-api-model:jar:1.4.0:compile
[INFO] | +- com.slack.api:slack-api-client:jar:1.4.0:compile
[INFO] | +- com.slack.api:slack-app-backend:jar:1.4.0:compile
[INFO] | - com.slack.api:bolt:jar:1.4.0:compile

Java Runtime version

openjdk version "1.8.0_252"

OS info

ProductName: Mac OS X
ProductVersion: 10.15.5
BuildVersion: 19F101
Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64

Steps to reproduce:

Hello, there.

I want to know why retry occurs.

Through the official document, I knew that a retry would occur if the response was not returned within 3 seconds, and I used AsyncMethodsClient to solve this problem. Nevertheless, the problem continues to arise.
The same problem also continues to occur even though the header of the Response object has returned the object X-slack-No-Retry: 1.

I want to know how to solve this problem.

[mwbrooks]

Hi @jayyhkwon,

Through the official document, I knew that a retry would occur if the response was not returned within 3 seconds, and I used AsyncMethodsClient to solve this problem. Nevertheless, the problem continues to arise.

Unfortunately, the 3 second timeout is a constraint of the Slack API and not the Java client. Regardless of whether we use the Synchronous or Asynchronous methods, the Slack API requires a response within 3 seconds of sending the request.

Using the Asynchronous client, you could respond to the Slack API immediately with a 200 ok. Then continue to process your long running jobs. When the jobs are complete, you can use the Asynchronous client to interact with Slack (e.g. send a message).

The same problem also continues to occur even though the header of the Response object has returned the object X-slack-No-Retry: 1.

This is interesting. I'm less experienced with Java and may need to put together a test example. However, looking over the sample code, I noticed that headers.put("X-Slack-No-Retry", Array.toList("1")); will return a list while the X-Slack-No-Retry header requires a string. Would the following fix this issue?

Map<String, String> headers = new HashMap<>();
headers.put("X-Slack-No-Retry", "1");

[seratch]

@jayyhkwon It seems your x-slack-no-retry code looks fine. However, I don't see a reason to return 400 Bad Request to the Slack API server in this scenario. Your app can simply return 200 OK within 3 seconds. As long as your asynchronous code works as you expect, return ctx.ack(); should work.

I guess the cause of your issue is related to other lines in your code (or time-consuming initialization stuff etc). Probably, other lines unexpectedly are taking more time than you think. Another quick solution I can suggest is to use the built-in ExecutorService. If your SlackEventProcessor provides a way to run code in another thread, you can go with it.

app.message("hello", (req, ctx) -> {
  app.executorService().execute(() -> {
    // do anything asynchronously here
  });
  return ctx.ack();
});

[jayyhkwon]

@seratch
thanks!
solved the problem because of your mention.

[seratch]

@jayyhkwon Great to know! I'm glad that we could help you out! 😄

[jayyhkwon]

@seratch
Hello, seratch.
its' another question.
Can i access Request object or Request Header in app.event method ?

The official document states that the value of the HTTP header X-Slack-Retry-Num indicates that the request is retry. But when I looked at the code, I couldn't find a way to access it as a Request object.

[seratch]

@jayyhkwon You can access request headers by req.getHeaders(). The req is the first listener arg in my above example.

[jayyhkwon]

@seratch
The first arg is EventsAPIPayload interface.
there is not getHeaders() method.
please correct me if i'm wrong.
thank you.

[seratch]

@jayyhkwon Ah ... you are right. I have to say there is no way to directly access request headers in listeners. I will take a look at possible ways to support this use case in the future versions. As a workaround, you can use a global middleware this way:

app.use((req, resp, chain) -> {
  String retryNum = req.getHeaders().getFirstValue("X-Slack-Retry-Num");
  req.getContext().getAdditionalValues().put("x-slack-retry-num", retryNum);
  return chain.next(req);
});
app.event(AppMentionEvent.class, (req, ctx) -> {
  String retryNum = ctx.getAdditionalValues().get("x-slack-retry-num");
  return ctx.ack();
});

[jayyhkwon]

@seratch
thanks a lot. work for me!