I tried to add breaks, using the breaks page, to most of my goals for around a week in late January. For five of my goals it inserted a break that starts in the past and extends to the end date of the desired break.
The issue being that the middle zero segment there should actually be a 6. The first zero segment, until October 29th, was (if I remember correctly) a past break, and the segment starting January 18th is the intended break.
Something similar happened to the book brigade group goal, though in that case there was the additional issue of permissions to add breaks to group goals.
I don’t know why this issue happened to only five of the goals I added a break for, and not the others.
Having written that, I now have a theory. I tried to change that middle zero segment to a six in the road editor, as I predicted it should be. This gave me an error graph, which I reverted with the “undo graph edit” button. I noticed that the goal total means that having that slope of 6 means it would reach the goal total before the break date.
I hypothesize that instead of reporting my requested breaks as invalid (as extending beyond the goal’s end date), the breaks page instead messed up and made this break retroactive.
(I like having my goals have end totals that I extend every so often. Much like calendialing, this practice is a way of raising to my attention the question of what I want out of my goals. Instead of coasting on autopilot, I have to occasionally affirmatively decide if I want each of my goals. That’s why I had five goals ending in the next few months. The book brigade issue happened also as we approached the end of the book and thus of the goal.)
Hi! Sounds very weird, definitely needs looking into. Could you email this through instead, though, so that I can assign it to Bethany’s queue? We’d also need the names of the goals involved, so that we can look at the logs.
This is one of those cases where I don’t think we can troubleshoot via the forum, since we do actually need to dig through logs and so on. Thanks!
After thinking it over a bit, my guess is that because the break’s start date’s rate is what determines the slope of the inserted pre-break row, and because the start date was after the goal was over and thus didn’t have rate, that rate defaulted to zero.
I unfortunately don’t currently have access to the Beeminder repo, otherwise I’d go looking to see if my hypothesis is correct. This is about as far as I can go with blind debugging, but it would be consistent with the observed behavior. (Of course, this is in addition to the failure of validation that allowed the invalid break through.)
Anyway, I’ve sent an email as requested, which also includes the above hypothesis.
Thanks for raising this @zzq ! I’ve managed to replicate it with a test goal: as you suspected, it’s because the break is after the implicit end date for the goal.
Your goal doesn’t have a “fixed” end date (via a Final Date), but it has an implicit one, back-calculated from the Final Value and Final Rate. Adding a break after a fixed Final Date isn’t allowed, so we probably shouldn’t allow one after an implicit end date either.
This is possibly related to why it can be difficult to resume an ended goal or extend one that’s about to expire without getting weird breaks and slopes.
