There Are Always Errors, But Are They Problematic?
Here’s a screenshot of the rollup page in TrackJS for the error. We can see it occurs sporadically, and has only affected 6 of our users in the last 30 days. I like to start at this page when debugging to get a sense for the impact and severity of a problem.
While the number of users impacted is not high, the error is impacting the
/account portion of the site. This is where users can change important customer information, or update their payment/billing. We really want this to work reliably!
This error is worth fixing (as opposed to ignoring with an Ignore Rule), the next step is diving in to the details.
The Error Details
The Plot Thickens
/subscription page. From the Telemetry Timeline I can see the error occurred on the
/team page, only about half a second after we navigated.
And anyways, we were coming from the
/shared/errors page, not anything subscription related. This code should never be running! But sure enough I can see from the timeline that Stripe is getting loaded, right after the user navigated to
/shared/errors. You can see they clicked the link, we made a PJAX request, the URL changed via
pushState and then the Stripe code loads.
I double checked the server template for
/shared/errors to make sure there’s no Stripe or billing related code. There isn’t. But… when a potential customer’s trial ends, we redirect (almost) every path to the subscription page. The user can still navigate to the
/account section and make changes, but instead of seeing their data they see a subscribe page for other routes. This could explain why the code is running on weird URLs. But why is it breaking?
The Network Ain’t Reliable
checkout.js file only if the user is on the subscription page. However, networks can be slow. In the event that the user clicks fast enough, and the
Reproducing the Problem Is Easy Now
I was quickly able to reproduce the problem by creating an expiring trial account. The big concern I had was whether this error was impacting billing actions. I was fortunately able to confirm that it was not. Without being able to reproduce the problem, there’s no way to know for sure though! Since the severity of this error is low, we’ll triage it to figure out whether it’s worth adding a defensive check, or better just to ignore it as there is no user impact.
Cannot read property 'Id' of undefined errors happen because the code is executing in an unexpected context. In our case, it’s because the user switched pages quickly, which is pretty likely to happen for highly-interactive applications like TrackJS. Unexpected things happen in production!
TrackJS gives you a lot more tools to figure out what’s happening than I covered today. Please sign up for a free trial and give it a try!