Promise.all vs Promise.allSettled in Javascript

Karan Kiri — Wed, 15 Mar 2023 14:19:10 +0000

Promise. all and Promise.allSettled is used to iterate over an array of promises. However, both have a few subtle differences, let's understand that in this article.

`Promise.all` method

Promise. all iterates over an array of promises and resolve to the array of values returned by each promise.

const tasks = [
    new Promise((resolve, reject)=> {
        setTimeout(resolve, 1000, "task 1")
    }),
    new Promise((resolve, reject)=> {
        setTimeout(resolve, 2000, "task 2")
    }),
    new Promise((resolve, reject)=> {
        setTimeout(resolve, 3000, "task 3")
    }),
]
Promise.all(tasks).then(data => {
    console.log(data); // ["task 1", "task 2", "task 3"]
})

If any one of the promises gets rejected then it immediately stops the execution and rejects with the error returned from the rejected promise.

const tasks = [
    new Promise((resolve, reject)=> {
        setTimeout(resolve, 1000, "task 1")
    }),
    new Promise((resolve, reject)=> {
        setTimeout(reject, 2000, "task 2 failed")
    }),
    new Promise((resolve, reject)=> {
        setTimeout(resolve, 3000, "task 3")
    }),
]
Promise.all(tasks).then(data => {
    console.log(data);
}).catch(error => {
    console.log(error); // task 2 failed
})

`Promise.allSettled` method

Promise.allSettled iterates over an array of promises and waits for all the promises to get either resolved or rejected. It resolves to an array of data with each promise's status in the following format.

[
  {status: "fulfilled", value: value1},
  {status: "fulfilled", value: value2},
  {status: "rejected",  reason: error}
]

Let's see what will be the output of the tasks2

const tasks = [
    new Promise((resolve, reject)=> {
        setTimeout(resolve, 1000, "task 1")
    }),
    new Promise((resolve, reject)=> {
        setTimeout(reject, 2000, "task 2 failed")
    }),
    new Promise((resolve, reject)=> {
        setTimeout(resolve, 3000, "task 3")
    }),
]
Promise.allSettled(tasks).then(data => {
    console.log(data);
})

// Output
[
  {
    status: 'fulfilled',
    value: 'task 1',
  },
  {
    status: 'rejected',
    reason: 'task 2 failed',
  },
  {
    status: 'fulfilled',
    value: 'task 3',
  },
];

This article is published w/ Scattr ↗️

Debugging a Production Issue: Lessons Learned from Solving a Date Parsing Bug in Chromium v110

Karan Kiri — Wed, 15 Mar 2023 14:18:46 +0000

Debugging a production issue can be a daunting task, but it's also an opportunity to learn new things and improve your skills as a developer. Recently, We encountered a production issue where one of the web pages in our application was not working. The issue turned out to be caused by a change in the behaviour of the Date.toLocaleString method, which was used to get AM/PM information. Let's start going through the events, and how it was reported to finally be fixed.

The Problem

One day, we received a support ticket stating that a particular webpage in our application was not working. The page was responsible for inviting new users to the particular account and displaying the details of all the users including when the user was created.

The first step in debugging any production issue is to gather as much information as possible about the problem and try to reproduce the issue locally.

I tried to reproduce the same issue on my machine but it was working fine. I asked my teammate to check if it was working for them. They were able to reproduce the issue. So we checked the console logs and found that there was an error in the Date parsing logic.

The initial instinct was that this could be an API/Data issue as we haven't done any deployment on the Frontend for some time.
We compared the date format from both browsers where it was working and where it wasn't and it was the same.

Now, the problem seemed weird because it was not happening for all the users. So we decide to check that on different browsers and found that the issue was happening for users on Chromium version >= 110, and it was working for all other browsers and Chromiums version below 110.

In the meantime, we communicated with the reporter that they can use other browsers to get unblocked while we debug the issue.

At this point, we knew something was broken in Chromium v110 but were still not sure what was breaking.

The next step was to run the same piece of code on the browser where it was failing, below is the sample piece of code that was failing in Chromium v110 with the following error

Uncaught TypeError: Cannot read properties of undefined (reading 'toLocaleUpperCase')

const date = new Date(createdAt);
const dateArray = date.toLocaleString([], { hour12: true }).split(' ');
const time = dateArray[1];
const ampm = dateArray[2].toLocaleUpperCase();

Now, was the time to check the value of dateArray in both browsers, the output was something like this

const date = new Date(createdAt);
const dateArray = date.toLocaleString([], { hour12: true }).split(' ');

// ['09/03/2023,', '0:47:09 am'] - Chromium 110
// ['09/03/2023,', '0:47:09', 'am'] - Other browsers

Now we're able to figure out that something is wrong with toLocaleString , to finally confirm the issue, We ran the below piece of code in both browsers.

const dateString = date.toLocaleString([], { hour12: true });
dateString.charCodeAt(19);

// 8239 - Chromium 110
// 32 - Other browsers

This confirmed that the bug was in the Chromium update and we were able to find the same bug reported in the Chromium project here https://crbug.com/1414553

The Solution

After identifying the root cause of the problem, We began to explore possible solutions. One solution was to update our code to use a different method for parsing the AM/PM information. Since we were using the date-fns library in our project, it was a pretty straightforward way to use the format function from the library and fix the issue

Here's an example of how the updated code looked like:

try {
    return format(createdAt, 'yyyy-MM-dd hh:mm:ss a') || '';
  } catch (error) {
    return '';
  }

After making these changes, We tested the fix in a staging environment and confirmed that the issue was resolved. We then deployed the fix to the production environment and monitored the logs to ensure that the error did not occur again.

Lessons Learned

Always make sure error handling is done properly in your code, in our case this led to the blank page
Never rely on a browser toLocaleString to parse date information, rather than use the formatToParts method which is reliable for parsing such information or you can use a dedicated library like date-fns

Conclusion

In conclusion, debugging production issues can be challenging, but it's important to approach the problem systematically and gather as much information as possible before attempting to fix it. In this case, the issue was caused by a change in the behaviour of the Date.toLocaleString method, which required a code update to handle the new behaviour. By understanding the root cause of the issue and implementing a proper fix, We were able to restore the functionality of the affected web page and prevent the issue from happening again in the future.