search

kingdonb / simplest-commitbee

Simplest commits-to/beeminder integration (roughly implements):
https://github.com/commitsto/commits.to/wiki#simple-beeminder-integration
MIT License
5 stars 0 forks source link

Data points should not be repeated #18

Closed kingdonb closed 2 years ago

kingdonb commented 2 years ago

Today, after I marked a promise as completed yesterday:

Screen Shot 2022-06-22 at 2 10 27 PM

(The promise has been re-counted again at every interval since it was accepted, this should reflect one single pip for the last day or two, not one every 4 hours since the promise was accepted...)

Screen Shot 2022-06-22 at 2 10 39 PM

The logs from this running process:

$ k logs -f simplest-commitbee-cron-7b568b99cc-fgqtm
Setting scheduler to bruno-/fiber_scheduler
calling Fiber.schedule for do_update loop
MyCLI::sync scheduled Fibers at 2022-06-20 15:13:37 -0400
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.000897228 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.00276972 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.003062997 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.014974644 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.016121618 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.002699398 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.019990443 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.024547146 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.027465365 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
heartbeat every 60mran the updater, sleeping now

heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.104668871 seconds
heartbeat every 60m
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
heartbeat every 60m
updater running again after 14400.002899615 seconds
beemind -t [ACCESS_TOKEN] -d '2022-06-20' simplest-commitsto 1 'success: update-docker-rvm-supported'
ran the updater, sleeping now
heartbeat every 60m

This madness can only be stopped by restarting the process, (now let's use this opportunity to exercise advanced debugging capabilities of VSCode and Okteto, we can get eyes on the problem and interact with it directly in our editor and on the cloud...)

kingdonb commented 2 years ago

The problem is definitely related to our new concurrency feature, since the program was originally designed to execute all at once, certain measures which were used to prevent "the expensive thing" from accidentally happening more times than required, have instead turned into cache false positives.

We're using stale data and need to refresh it so our next calculation does not come out as if we hadn't already placed the pip