Recently, we started to receive issues from our company’s SSO. For the past six months or so we’ve been load testing, they have had an impeccable record. However, starting this release, we’re getting a handful of users that get stuck in a state where we have an access token, but getting a bearer token from the service fails. This results in a weird state in our load test where they technically pass authentication, but fail identity. Since a “user” in the load test persists session between iterations, that meant those users would continue to fail their tests over and over again, resulting in thousands of exceptions on the server, affecting response time for other, working users.

What we wanted to do was detect this issue in the web test, then clear out cookies so the user effectively came in clean and could retry SSO. The issue that we faced, which we didn’t realize we’d face going in so it took us longer than we anticipated, was that context parameters renew every iteration. So, we had to find a mechanism that persisted values between iterations but stayed within the context of the user with the issue. Fortunately, this StackOverlow question provided us a solution for that.

Step 1 – Create a web test request plugin to capture the issue

There is no web request plugin that will update a parameter based on the outcome of the previous response. We could have made a much more dynamic plugin, but this one served our purposes just fine.

What you’ll notice in this class is that we try to update both web test context parameters and the user context parameters. While we weren’t trying to overdo this for our purposes, we also wanted to account for both in the case we reuse this and we wanted to key off a context parameter mid-instance run.

Obviously, we could have done much more with this plugin, but like I said, it served what we needed.

Step 2 – Create a web test plugin to clear cookies

With the flag being set, we could now clear the cookies next time the instance started up. Initially, we thought the post-web test overrides would fire even in the event of a run failing, but that is not the case. It seems if a run fails, it just exits out and starts up a new one, which is somewhat disappointing and led us to search for a way to persist values between runs. We already had a clear cookies plugin, so we just expanded what we had.

If that is true, then we instantiate a new CookieCollection and set that to the context’s property.

Step 3 – Triggering these two plugins

With these two created (and make sure you build your project before you try to use the plugins), you simply add the SetContextParameterTrueByResponseCode plugin to any web request and add the ClearCookies plugin to the web test itself. The two will take care of the rest.