Ruuter mixing up responses when multiple requests in parallel using conditions

[gdrui]

Given an endpoint that fetches different data from Resql based on the provided parameters:

extract_request_data:
  assign:
    requestedMetric: ${incoming.params.metric}

checkMetric:
  switch:
    - condition: ${requestedMetric === 'total_chats_day'}
      next: getTotalChatsDayResults
    - condition: ${requestedMetric === 'total_chats_month'}
      next: getTotalChatsMonthResults
    - condition: ${requestedMetric === 'total_chats_no_csa_day'}
      next: getTotalChatsNoCSAResults
    - condition: ${requestedMetric === 'avg_chats_by_month'}
      next: getAvgChatsMonthResults
    - condition: ${requestedMetric === 'avg_chats_by_week'}
      next: getAvgChatsWeekResults
    - condition: ${requestedMetric === 'avg_chats_no_csa_by_month'}
      next: getAvgChatsNoCSAMonthResult
    - condition: ${requestedMetric === 'avg_chats_no_csa_by_week'}
      next: getAvgChatsNoCSAWeekResult
    - condition: ${requestedMetric === 'avg_waiting_time_day'}
      next: getAvgWaitingTimeDayResult
    - condition: ${requestedMetric === 'avg_waiting_time_week'}
      next: getAvgWaitingTimeWeekResult
    - condition: ${requestedMetric === 'total_forwarded_chats_yesterday'}
      next: getTotalForwardedChatsResult
    - condition: ${requestedMetric === 'chat-activity'}
      next: getChatActivityResult
  next: invalidMetric

If this endpoint is called once with any valid parameter it will return the correct result.
However if many or all of these options are called in parallel requests then sometimes the results get mixed up and for example I can receive the result of avg_waiting_time_day when the request was with the parameter total_chats_day

I also tried to replace the individual steps so that instead of an asynchronous http.post step each step would only return a unique value like :

getTotalChatsDayResults:
  return: 'A'
  next: end
  
getTotalChatsMonthResults:
  return: 'B'
  next: end
...

This seems to happen less frequently like this, but I still observe the same thing happening:

When its OK:

When its not OK:

[gdrui]

Here is a complete Ruuter DSL

extract_request_data:
  assign:
    requestedMetric: ${incoming.params.metric}

checkMetric:
  switch:
    - condition: ${requestedMetric === 'a'}
      next: getA
    - condition: ${requestedMetric === 'b'}
      next: getB
    - condition: ${requestedMetric === 'c'}
      next: getC
    - condition: ${requestedMetric === 'd'}
      next: getD
    - condition: ${requestedMetric === 'e'}
      next: getE
    - condition: ${requestedMetric === 'f'}
      next: getF
    - condition: ${requestedMetric === 'g'}
      next: getG
    - condition: ${requestedMetric === 'h'}
      next: getH
    - condition: ${requestedMetric === 'i'}
      next: getI
    - condition: ${requestedMetric === 'j'}
      next: getJ
    - condition: ${requestedMetric === 'k'}
      next: getK
  next: invalidMetric

getA:
  return: 'A'
  next: end

getB:
  return: 'B'
  next: end

getC:
  return: 'C'
  next: end

getD:
  return: 'D'
  next: end

getE:
  return: 'E'
  next: end

getF:
  return: 'F'
  next: end

getG:
  return: 'G'
  next: end

getH:
  return: 'H'
  next: end

getI:
  return: 'I'
  next: end

getJ:
  return: 'J'
  next: end

getK:
  return: 'K'
  next: end

invalidMetric:
  status: 400
  return: 'invalid metric requested'

Here is a sample index.html that will call this endpoint and count failed requests

<script>
  const metrics = 'abcdefghijk';

  let issueCount = 0;
  let passCount = 0;

  const getAllMetrics = async () => {
    const promises = [...metrics].map((m) =>
      fetch(`http://localhost:8080/overview/metrics?metric=${m}`).then((r) =>
        r.json()
      )
    );
    const results = await Promise.all(promises);
    checkResults(results);
  };

  const checkResults = (results) => {
    results.forEach((r, i) => {
      if (r.response === metrics[i].toUpperCase()) {
        passCount++;
      } else {
        issueCount++;
      }
    });
    document.open();
    document.write(
      `<h3>Good requests: ${passCount}</h3><h3>Bad requests: ${issueCount}</h3>`
    );
    document.close();
  };

  setInterval(() => getAllMetrics(), 1000);
</script>

As long as Ruuter is set up to accept CORS from http://localhost:3000, you can serve this index.html with
npx http-server -p 3000 -o -a localhost in the same folder where the index.html file is.

After keeping the tab open for a little while, this is the result:

[joonasroosalung]

Explained this somewhere in chat but will explain here as well. In my opinion this goes against the usual logic of how Ruuter conf's are written. This type of request with a url parameter, should pass a variable to resql. In that case the heavy lifting would be done in sql. Another way would be to make each of these requests a separate Ruuter conf.

Essentially this does not seem a likely scenario to happen and not something that should be encouraged. Additionally there was previously a bug with the switch step, where a request could not go into the "else" condition, which was fixed here #122. So if we insist this is an issue, this should be checked again with this fix.

[gdrui]

I'm afraid it is still an issue after this fix.

It doesn't look like an issue related to the switch step specifically, I think it's more about running multiple requests on the same endpoint that expect different outputs.

The Ruuter endpoint is composed of valid and very simple steps: A condition with multiple options and just a simple return statement.

The same thing happens with just 2 conditions, the point is that a request can get a response meant for some other request that happened to occur at roughly the same time. Also this means one client can get a response meant for another client when they make a request to the same endpoint at similar times. This is obviously a serious issue with very real consequences.