Jest test array with objects without order

Hello internet!

As I was doing my regular weekday I met a surprisingly unsolved problem in Jest, namely what if I wanted to test an array's _content without order_?

So e.g. these 2 arrays should equal

[{cat: 'Takira'}, {cat: 'Inari'}]

and

[{cat: 'Inari'}, {cat: 'Takira'}].

There is an SO post about this, but it doesn't care about objects, but only primitives. Also it points to Jasmine (which does have this as a native feature), but not Jest.

So here is my generic solution to the problem

for (obj in array) {

    expect(obj).toEqual(

        expect.arrayContaining([

            expect.objectContaining(obj)

        ])

    );

}

Let's go through this step by step!

So we are looping through the array (so far so good) and then we simply expect that object to be in the array.

That's literally it.

Thank You For Coming to My TED Talk.

A painful lesson I learned while putting out fire

Imagine you have a service that's unresponsive, yet you can see in your production environment it yields 500-s for every request. SLO-s are fine, no alert is being invoked, everything seems to be normal.

What do you do?

At first, I didn't know what to do, but after the first shock I had the - not that imaginative - idea to restart the service. For our production evnironment we use shipit as a helper for these kind of situations. As a long time software engineer I am familiar with a lot of tool, but this was the first time looking at the shipit user interface. So I went back to my roots where we restarted services by a new deployment. That was arguably not the best decision I admit, yet there I was trying to put out fire. The new deployment went through! Everything should be back up again and running smooth like a sailboat! Right. Right? Right??

Well, this should've been the case, but when I went back to check on the service, it showed still the same error. Bummer.

What to do now?

Let's check logs.

OK, logs show practically nothing. I mean, nothing for the past 10 minutes.

That's not good.

How will I know what's happening inside the container?

OK, calm down. This is a great challenge that you can solve. Embrace it.

Cool, let's have a look what was the last thing the container logged!

Maximum call stack size exceeded.

That's not good. What could possibly cause that so badly that the service stops reporting?

Let's check the stacktrace.

Something-something.. loggerInstace .. something-something.. winston..

Ok, so something's wrong with logging? 

Ouch.

So we don't know anything about the inner parts of the service, because the _logging_ has issues.

In the meantime I tried to redeploy again, same result - 500-s after the deployment.

This is not looking good.

BUT! Teammates are there for you when you them the most! Sergei taught me that Shipit has a "restart" feature!

OK, let's do that.

It works.

WHAT.

Damn.

So when we deployed shipit didn't actually do any changes? Weird.

Let's check the kubernetes pods.

They are old. They definitely didn't restart when I redeployed.