It looks like my station (Marcs - 101) got 1000 more data in the last day (and almost got 20 places in the db leaderboard).
How is it possible? I did not get a particularly unusual amount of data today.
I saw the same jump for other stations (F6KKR).
Looks like there was some free-time to transfer “old data” from network to DB… Maybe @cshields could turn a light on!?
Unfortunately, no… and thanks for bringing this to our attention as there’s a pretty big bug…
Looking in the db of db, there are duplicate and triplicate entries for @n5fxh …
The task that we have running to sync frames from network to db is running every 15 mins (despite being configured to run every minute… hmm). However, due to adding more transmitters and gathering more data, (along with an unrelated error getting thrown by a > in the CMD list from ISS BBS), some of those runs are going longer than 15 mins and another run is causing a sync to be queued before the previous sync is checked to be synced.
My suspected culprit (and fix) is going to be in the calling of demod_to_db as a celery task, which allows it to queue multiple times. This could/should be handled by the parent task, and in hindsight I see no reason the individual task needs to be a celery task of its own (which may help speed things up in the end). That said, I’m going to pull @Acinonyx into this thread as a second set of eyes.
My suggested fix for this:
- move demod_to_db to utils instead of a celery task
- the sync_to_db celery task will iterate through each demod instead of queuing them
- add a check to demod_to_db that looks for the decoded flag before continuing, as an added protection
The duplicate problem has been fixed in prod now… However, note that we haven’t done any cleanup work on existing dupes (yet).
I did not see any more anomaly since last time.
I will warn you if I see another jump (I shall see the cleaning work).