SOS: Too Many Toasts 🍞🍞🍞
How we stopped spamming doctors with toast error messages.
At Doctolib, we're in a constant sprint to deliver more value to doctors, so we're always on the watch for their suggestions, but also complaints.
How we spotted the issue?
Together with Romain Choquet, our Principal Engineer, and Marine Diot, Product Manager, we recently composed a task force to tackle a non-negligible list of user feedback, mainly about performance and reliability.
After several bug fixes, calls to doctors and New Relic dashboards, we've been faced with this very interesting Instagram story:
That's it. No further info. So let the investigation begin 🕵🏻♂️
Finding a way to reproduce the issue
First things first, we were intrigued by the "loop" part of it. Why were we showing all those messages? And how could they possibly loop? To answer those questions, our number one tool is New Relic.
Notice that I'm not sharing a New Relic affiliate link.
If I recommend them, I do it from the ♥.️
The first thing we want to figure out, then, is who was one user who has faced this issue. This way we can gather more info on how to reproduce it.
For that, we need to find the spikes. So we group the spikes by account, we increase the granularity to show occurrences per hour, we plot this info into a time series format, and bam! There we go.
Let's pick Nov 28th, for instance, where we had a single account with ~60k toasts, and let's narrow that down a little more…
On this specific day, one single doctor had about ~15k toasts in under 10 minutes. That happened several times during the day.
Shall we say that's unacceptable behavior? Sure.
So let's take a look at the source of the errors:
206,000 messages in a single day. For a single account.
And all the errors come from a single endpoint.
I guess, with that, we're ready to reproduce the issue:
- so we connect to the staging environment
- we block the requests to this specific endpoint
- we try to navigate to the next week (to trigger a call to this endpoint)
- and there it is! Toasts. Toasts everywhere 💥
It looks bad, but it's actually great news. And that's because, in most bug investigations, once you get to the point where you can confidently reproduce the issue, it’s just a matter of time until you have it fixed.
So let's make it happen.
Making toast messages relevant again
Before jumping in to fix the bug, it's good practice to take a step back and put ourselves in the shoes of our users. By doing this exercise, we aim to improve the chances that our solution will be adding value and not create another issue for our users.
The first thing that comes to our minds is:
As a doctor, I don't care about duplicate error messages, containing the exact same text, because they do not provide any additional value to me.
So by considering this assumption, let's implement our first fix.
Stop showing duplicate toasts
As you see from the code below, that's a quite straightforward fix. We only check if the new toast message already has a duplicate. If it does, we return the existing list of toasts. If it does not, we add the new toast to the list.
setToasts((currentToasts) => {
const isDuplicate = currentToasts.some((toast) => toast.message === newToast.message)
return (isDuplicateError) ? currentToasts : [...currentToasts, newToast]
})We're good: once live, doctors won't be bothered by duplicate toasts. 🙏
Very nice. So let's commit, push, open a pull request and while we wait for the CI, let's take another look at our New Relic results. What are other impacted endpoints?
So here we are, back to investigating. And this time we realize that many of the endpoints are related to polling features, i.e, they're periodically called by a background task with no user action involved.
"No user action involved"? 🤔 It makes us think that:
As a doctor, I only care about failures coming from my own actions.
If there's a failing background task, then I don't care.
Couldn't agree more. So let's go for the second fix.
Stop showing toasts related to background tasks
Fortunately, we have the polling logic encapsulated inside a React hook. Unfortunately, this hook is not used by all of our polling's (ofc 😅).
No problem. We implement a series of small fixes…
…and we're ready to ship to production.
At Doctolib, we deploy to production multiple times a day, so the time it takes to see our changes going live is fairly short. However, if users don't refresh their browsers, it might take a little longer to propagate changes.
After a few days, we finally see the expected results:
We’re only fixing something that should not have been there in the first place. But I do hope that doctors will have an improved experience, with fewer distractions and be more deeply focused on the core of their jobs 🤗
At Doctolib, we’re building a team of entrepreneurs to change the future of healthcare. If our mission is appealing to you, then take a look at our open positions.
