I have a tool that I wrote, probably 5+ years ago. Runs once a week, collects data from a public API, translates it into files usable by the asterisk phone server.

I totally forgot about it. Checked. Yep, up to date files created, all seem in the right format.

Sometimes things just keep working.

[–] RustyNova@lemmy.world 51 points 20 hours ago (2 children)

Meanwhile, had to debug a script that zipped a zip recursively, with the new data appended. The server had barely enough storage left, as the zip took almost 200GB (the data is only 3GB). I looked at the logs, last successful run: 2019

[–] r00ty@kbin.life 17 points 20 hours ago (1 children)

Yes, had the same happen. Something that should be simple failing for stupid reasons.

[–] RustyNova@lemmy.world 12 points 18 hours ago (2 children)

Well it's not that simple... Because whoever wrote that made it way too complicated (and the production version has been tweaked without updating the dev too)

A clean rewrite with some guard clauses helped remove the haduken ifs and actually zipping the file outside of the zipped directory helped a lot

[–] r00ty@kbin.life 6 points 17 hours ago

I mean, I have to say I've hastened my own demise (in program terms) by over-engineering something that should be simple. Sometimes adding protective guardrails actually causes errors when something changes.

[–] Quantenteilchen@discuss.tchncs.de 2 points 16 hours ago (1 children)

Am I understanding that last part correctly?

[...] and actually zipping the file outside of the zipped directory helped a lot

Did they just automatically create a backup zip-bomb in their script‽

[–] RustyNova@lemmy.world 8 points 15 hours ago

I oversimplified it but the actual process was to zip files to send to an FTP server

The cron zipped the files to send in the same directory as the zipped files, then sent the zip, then deleted the zip

Looks fine, right? But what if the FTP server is slow and uploading take more time than the hourly cron dispatch? You now have a second script that zip all the folder, with the previous zip file, which will slow down the upload, etc...

I believe may have been started by an FTP upload erroring out and forcing an early return without having a cleanup, and progressively got worse

... I suppose this happened. The logs were actually broken and didn't actually add the message part of the error object, and only logging the memory address to it

[–] adavis@lemmy.world 2 points 18 hours ago (1 children)

Need some monitoring!

[–] RustyNova@lemmy.world 13 points 18 hours ago (1 children)

Oh no need. The client didn't noticed anything in 6 years, and the reason why we had to check is because they wanted us to see if we could add this feature... That already existed.

[–] elvith@feddit.org 7 points 17 hours ago

My favorite part is, if you do some extensive analytics from time to time (e.g. to prepare an upgrade to a new major version) and as a side effect stumble upon some workflows/pipelines/scripts constantly failing (and alerting the process owner) every five minutes for... at least a few months already.

Then you go and ask the process owner and they're just like "yeah, we were annoyed by the constant error notification mails, so we mad a filter that auto deletes them"...

[–] Gonzako@lemmy.world 19 points 21 hours ago (2 children)

Yeah, all these simple data processing scripts will always work as long as both sides stay the same/compatible

[–] r00ty@kbin.life 20 points 20 hours ago

Yep. It seems they haven't changed a thing about the format. Probably a script much older than mine on their end is generating it too.

[–] MonkderVierte@lemmy.zip 8 points 20 hours ago (1 children)

Isn't that true for all of data processing?

[–] Gonzako@lemmy.world 7 points 20 hours ago

Maybe. But webdevs have made it a mission not to seem like so