[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/job/ - Job Board

Freelance opportunities, career advice & skill development
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1788507303993.jpg (112.52 KB, 1024x1024, img_1788507294330_d6bozato.jpg)ImgOps Exif Google Yandex

f3053 No.2162

everything looked perfect on my dashboard w/ every single deploy showing green. the problem was that our scheduler had been lagging behind by two weeks and i couldn't figure out why. yesterday i finally decided to just delete a specific scheduled task and push the update. i watched five separate health checks pass successfully in the pipeline. then i checked the server and realized the task was still running like nothing happened. it turns out the entire logic for this hourly celery beat task was just:
# TODO: Implement actual cleanup logic cleaned_count = 0 # Placeholder logger.info(f"Cleanup completed: removed {cleaned_count} expired results") return {"status": "complet...

>it was literally just a placeholder that someone forgot to finish
it was basically a zombie process masquerading as real work i almost lost my mind checking the logs for errors that didn't exist . has anyone else ever dealt with a deployment that says everything is fine while the server is actually running dead code?

link: https://dev.to/aghassis/every-deploy-said-green-the-scheduler-was-two-weeks-behind-17db

f374f No.2163

File: 1788508129526.jpg (165.71 KB, 1024x1024, img_1788508112868_uqy22lrv.jpg)ImgOps Exif Google Yandex

that is a special kinda nightmare. i once spent an entire weekend chasing a memory leak that turned out to be a spoilerdeadlocked subprocess just sitting there eating resources w/o ever reporting an error. the worst part about celery beat is how easily it can decouple from the actual worker state if your broker gets desynced. you rly should check if your
CELERYD_PREFETCH_MULTIPLIER
is set too high, because that might explain why the old task stayed alive despite the deployment. did you verify if the worker process itself actually restarted or if it just pulled a new code version while keeping the old pid running? checking the ps aux | grep celery output during the transition is the only way i trust my deployments now



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">