We built a small registration tool for customer appointments in store. Basically a list of appointments with customers.
End of last year the store employees started calling in saying 'The list is empty and no matter how many appointments I put in for today, I can't see the customer.'
We looked in the database and there they were. All appointments were there. So the bug hunt was on!
Good for us: Our Dev-Systems showed the same behaviour. So we chased the flow of the date from database to representation. When we found the problem half an hour later, we had a good laugh. Note that this was not a system critical function and the store employees are smart people, that figured out a way around this. The bug was that someone switched yyyyand YYYY. One is the week year and one is the actual year. Since last year the 30st of December was already in week 1 of year 2020, the date was completely wrong and the list filtered for dates newer than 30st of December 2020.
It was a mere coincidence, that the problem did not happen in the beginning of 2019.
A Freelance DevOps doing container stuff and automating unhealthy amounts of software.
Need something automated or containerized? Feel free to hit me up :)
I feel this so much, something similar happened to me a few days back.
When I tried to find out why our server grabbed and served old reports from our storage.
What I wanted: YearMonthDay-HourMinute, something like this: 200626-1030
Which I quickly slapped together via the linux's date tool
currDate=$(date +%y%m%d-%H%m)
After that innocent little line would be some sorting logic to determine the most recent report on our storage (s3 minio in this case), before it would be ultimately chosen and pumped into our report-serving container.
This one typo took me hours to find, I was so confused as to why it always grabbed the wrong reports. After a few hours my colleague noticed that the minutes were always the same. So after a quick look at the sorter, we saw that one incorrect lower case m
We built a small registration tool for customer appointments in store. Basically a list of appointments with customers.
End of last year the store employees started calling in saying 'The list is empty and no matter how many appointments I put in for today, I can't see the customer.'
We looked in the database and there they were. All appointments were there. So the bug hunt was on!
Good for us: Our Dev-Systems showed the same behaviour. So we chased the flow of the date from database to representation. When we found the problem half an hour later, we had a good laugh. Note that this was not a system critical function and the store employees are smart people, that figured out a way around this. The bug was that someone switched
yyyyandYYYY. One is the week year and one is the actual year. Since last year the 30st of December was already in week 1 of year 2020, the date was completely wrong and the list filtered for dates newer than 30st of December 2020.It was a mere coincidence, that the problem did not happen in the beginning of 2019.
I feel this so much, something similar happened to me a few days back.
When I tried to find out why our server grabbed and served old reports from our storage.
What I wanted: YearMonthDay-HourMinute, something like this: 200626-1030
Which I quickly slapped together via the linux's date tool
After that innocent little line would be some sorting logic to determine the most recent report on our storage (s3 minio in this case), before it would be ultimately chosen and pumped into our report-serving container.
This one typo took me hours to find, I was so confused as to why it always grabbed the wrong reports. After a few hours my colleague noticed that the minutes were always the same. So after a quick look at the sorter, we saw that one incorrect lower case m
I screwed that one up, but was so happy someone else saw what I couldn't find.