A day solving problems at work with some out of the box thinking

I will write today about my workday from yesterday and how it progressed. The morning didn't announced anything exciting for the day and I was supposed to do some automation which is an ongoing activity without an end date. But besides this there some external customer tickets that were escalated to us for few weeks and I was supposed to take care of those. I have done some updates on those, but mostly in the direction of requesting more information from the customer, which means basically that I didn't want to work too much on them (or at all) and simply delayed that be requesting more logs and other things. But at the end of previous week they responded with that and in the corner of my mind there was the fact that I need to resume the investigation on them. So that's what I did, but let me tell you a little bit more about it.

The issues were basically encountered just in a Production environment and with specific messages that different customers would create. I couldn't replicate that on our side in the past as we usually build the message correctly and those don't go wrong even during Performance tests. But when it comes to different customers from different countries doing their own implementations, things can go wrong. And in such cases the investigations is a pain in the *** and it is hard to identify what's wrong with that, either in our code or theirs. But I came up with a solution also for that and there's where my creativity, experience and geniality kicked in. 😆

What I did was to build a way that we could reply messages that were created by other third parties. Those messages even if they are created by them and are encrypted in a specific way, my implementation succeeds to destructor it and rebuild it as a message send by my behalf. This way I am tricking the system under test to accept the receiving message and replay it as it was from that specific environment without falling validations. So I had two different context when messages would fail and I went up and replayed both of them.

And of course this way I could replicate the Production issues. Now we were preparing for a new release, but with the identified problems that translated into 2 new Critical tickets, the release was delayed. Now it is the moment when Developers came into the equation and since than I am helping them to debug the issues. It is not certain that the issue resides within our system as third party environments can have problems on their own. So it remains to be seen what's the issue and where it resides.

But what I wanted to highlight with this story is that sometimes we need to think outside of the box. I could simply say that I cannot replicate their problems one way or the other, but I found a way to replay their messages/requests and get the same issues in a controlled Test environment. That doesn't mean it is a Bug in our code, but it offers a quick way to replicate issues locally and hand over the investigation to the developers. And to tell you the truth, having this implementation done by me, they shouldn't fire me for the next 5 years just for that piece of code. 😆😆😆 Kidding, anything can happen.