Consider using a graph instead of a list when applying rules

[allansson]

What

Currently when applying rules, e.g. correlating values, we store the requests in a list. The UI presents the request in a similar fashion: as a log. This representation of requests implies that the requests happened sequentially and rules are applied as if they did, but that's not an accurate representation of what really happened.

Since requests can happen in parallel the more accurate representation is a graph, where the ancestors of a request X are the requests that ended before the request X started.

Treating requests as sequential can create subtle issues:

Time	Event
1	GET-request X started.
2	POST-request Y with body { id: "123" } started.
3	POST-request Y received response.
4	GET-request X received response body { id: "123" }

In the above table request Y starts and completes while request X is in progress, so it is clear that the id posted cannot have come from the response of request X.

But treating the requests as a list means that a correlation rule could see the response body of request X and think "Ah, this must be the same id as the one in the request body of request Y" (in this case it applies if requests are sorted by start time, but the same applies if sorted by end time if you change the order in the table).

If we instead use a graph where every ancestor of a request has ended before the request has started, request Y could never be correlated with request X, because request X ended after request Y started.

Why

Doing this will help rule out correlations that couldn't have happen, leading to more accurate results.

Considerations

Since we only visualize requests as a log, users have no way of knowing if two or more requests happened in parallel. Looking at the log they might conclude that the value from one response should be correlated with a value in a request, but in actuality the requests were parallel and could not be related.

We might have to have an alternative view to make the relationships between requests more obvious.

Alternatives

An alternative solution would be to treat the request and response as two separate events when applying rules. The extractor part would only look for response events and replacers would look for request events.