Here’s a fun one I wouldn’t have spotted for quite a while longer, had I not smashed my phone last weekend. Long story short, I dropped my Google Pixel 6 shattering the screen, and decided to switch to iPhone for the first time… ever.
Related to the RangeError problem in the title, but not to me smashing my phone, I spent Saturday this week making some changes to one of my other sites: HighestPayingJobs.co.uk. Whilst I was doing that work, I realised another recent change I made, something scrapes the Consumer Price Inflation data from the ONS hadn’t updated on the front page.
When I looked more deeply into it, I realised that it was very likely a cron job problem. I’d set my cronjob as follows:
0 0 * * 0 cron_inflationWhich for the unfamiliar means “At 00:00 on Sunday”.
The problem was the inflation statistics had come out midweek, and then the cron hadn’t yet run, so the site wasn’t showing the info I expected.
OK, still not directly related to this RangeError problem, but I am getting there. It’s important for me to give you context!
Soooo, getting to the problem at hand, or at least, how I discovered it: Last night (Sunday at the time of writing) I thought to check the site to see if it had updated yet. I checked on my iPhone and …
Given I’d been working on the site the previous day, and my downtime detector wasn’t hammering me, I figured this must be a Safari bug. Actually if I pressed refresh, the page very briefly showed before crashing, so I was fairly confident things were only screwy in Safari.
Well, I wasn’t going on my computer to figure out that at the time. So I left it for future Chris to worry about. Thanks past Chris!
I don’t think you can load up the Developer Tools on a phone. You couldn’t do that on a Google Pixel in Chrome, and my experiences with iPhone so far have been a bit more … well, how show I say it, wrapped in bubble wrap? So I doubt it’s possible, but you never know.
Fortunately I do have a desktop Mac with Safari installed.
Here’s what I saw from that point of view:
Much easier to figure out. Some issue with the AverageUKSalary component. It’s a React / Next.JS site so that stack trace gave me everything I needed.
It actually turned out to be this line:
const inflationIsoMonth = Date.parse(
`${inflationData.mostRecentAvailableYear}-${inflationData.mostRecentAvailableMonth}-01`,
);Code language: TypeScript (typescript)It turns out Date.parse is not a reliable way to work with dates from the perspective of web browsers.
It’s better to use the Date constructor instead.
What that meant was a quick code change to:
const inflationIsoMonth = new Date(
inflationData.mostRecentAvailableYear,
inflationData.mostRecentAvailableMonth,
);Code language: TypeScript (typescript)I should still probably throw in a bit more error handling around the object being invalid, or the values being NaN or whatever. If I had used an error boundary the rest of the site wouldn’t have blown up for one ‘small’ issue.
I should also probably check the rest of the site, too.
However I have a bigger change to come that I guess I’ll do a thorough test after deploying.
The truth is, not that many people use the site (sadly), so it’s not the end of the world.
I did wonder how many people might have been impacted:
But that’s not quite fair to say 40 people.
Firstly, two would have been me, testing on both iPhone and OSX desktop.
And this Average UK Salary thing was only added about two weeks ago.
Anyway, basically don’t use Date.parse.
Focker, out!