Summer break is over and the RootCause team is back to business! Recently I added a frequently requested and major feature to RootCause: The ability to record and replay AJAX requests/responses during your user’s sessions. By Ajax, I mean the most common types of client-to-server requests and server-to-client responses sent using the XmlHttpRequest object. During replay, this feature helps you match the user environment by replaying not only the user actions but also the captured requests and server responses initiated by those actions. This of course increases the chances to reproduce the logged defect in a controlled debug environment.

With this new option enabled, no actual XHR requests are sent to the server during the replay session. All server responses are emulated and filled in with the previously logged data, which protects you from executing a potentially harmful server-side operation during the session replay. For example, if an issue in your application happens when deleting the last user in the system, replaying the logged issue session over and over again will not lead to all users being deleted

How do I enable this feature?

To enable the feature you simply modify your RootCause logger configuration and add a new configuration option. The feature is controlled by the enableAjaxPlayback option which is false by default. Set it to true to enable it.

var logger = new RC.Logger({
     enableAjaxPlayback : true,
      …
});

New Replay Studio GUI elements

When you have logged a user session with the feature enabled, the Replay Studio will provide you with additional information about requests and responses. Each request and response entry in the action list will have a small info icon, hover over it to see the request or response information logged. The request information typically contains a timestamp, URL, query parameters, request method, request headers and a payload.

XHR request info GUI

The response information will contain both response and the corresponding request information.

XHR request info GUI

How does the request recording work?

During a user session, the logger will replace XmlHttpRequest object constructor with its own function and provide your application with a modified version of XmlHttpRequest object each time it creates one directly or via any wrappers like $.ajax or similar. The object’s open and send methods will be replaced with custom ones having logging facilities added, everything else is left untouched.

How does the request/replay emulation work?

At session replay time, the XmlHttpRequest object is mocked using the great nise.js library (a micro library for AJAX mocking). The library also substitutes the original XmlHttpRequest object constructor function with its own implementation providing the application being replayed with a modified XmlHttpRequest object allowing us to intercept AJAX requests and mock the responses to fill them with the recorded data.

Important considerations & limitations

We do not guarantee that all AJAX request will be intercepted during recording or replaying time. During logging, any XHR request made before RootCause logger is initialized will pass through without being logged. The same goes at session replay time, any request your application makes before the Logger is initialized will pass through to the server. Thus if your application business logic involves some server side operations potentially harmful to your clients data, please make sure to replay only in a controlled debug environment (and not in production). Do not consider this feature to be 100% bullet proof, protecting you from AJAX requests being sent during session replay.

For Ajax response recording, we currently only support text or JSON payloads. Other payload types like: array buffers, blobs, XML documents are to be supported in a future release. Additionally there are other ways to send a request to a server, such as Fetch and WebSockets to name a few. We will cover those options in time, but currently we intercept only network queries initiated with XmlHttpRequest objects.

Conclusion

With this new feature we’ve taken another important step forward and made session playback even more stable. We hope it will help you improve the quality of your applications and that it will be another useful tool in your debugging toolbelt.

As always we are always here to listen to your feedback. Bug reports and feature requests are welcome: http://therootcause.io/forum/

Happy bug fixing! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">