Odd road behavior upon "Commit To" rate change (was: Odd "weekends off" behavior upon turning the feature on)

So I just upgraded to Bee Plus and decided to try out the Weekends Off feature on one of my goals.

First I changed it from 5 a week to 1 a day, as suggested here(*). Then I checked the Weekends Off box. And then I saw this:

(*) There’s no link on “here” because I couldn’t actually find where I’d read that. It isn’t in the FAQ, searching the forum didn’t turn it up, and the blog is non-searchable. The blog really should be searchable. Anyway, I read somewhere recently that you recommended moving to per-day units before turning on the weekends off feature.

In case it’s helpful, here’s what the road editor now looks like (all generated by checking Weekends Off; I haven’t touched the road editor yet):

Note that the second row, through Oct 25 at a rate of 5, was on a weekly rate…wondering if it somehow retro-interpreted that rate to 5 daily back to the goal’s start? In which case perhaps the issue is with the changing of the rate, rather than the Weekends Off feature…unfortunately, I can’t say for sure, because the graph was still the placeholder when I checked Weekends Off.


Additional wonkiness: I just got an email telling me I derailed on this goal.

1 Like

I don’t have anything useful to add but :thumbsup: on topology as an excellent thing to have a beeminder goal about (I just have a generic “maths” one).

1 Like

I agree the blog ought to have a search box. Although it works pretty well to just google “beeminder” plus whatever you’re looking for. Beeminder blog posts tend to be the top hits. That’s how I just found the advice you impressively recalled from 5 months ago to use “per day” as the rate units when using weekends-off:


PS: Thanks so much for all the bug reports! You’ve more than earned Beeminder stickers if you’d like some – just DM me your snail-mail address.

1 Like

Thanks, Danny! I don’t know what I’d do with stickers, but if you had Beeminder t-shirts, well, I’d wear the heck out of one. :slight_smile:

(I think t-shirts would be a great thing for you guys to have! A Beeminder store with Beeminder merch for the so-in-love trufans! If you do start offering t-shirts, please offer “women’s cut” ones, too. Not to jump the :gun: or anything.)


More data on this issue (also sent to support via email; posting here for completeness’ sake, future reference, etc and so forth).

After yesterday’s test case snafu got fixed by the fabulous Chelsea and Bethany, I tried the change on a second goal. Turns out the Weekends Off feature is not the culprit (hence the change of thread title). It’s the “Commit To” rate editor. I changed my guitar goal from 5/week to 1/day. Before and after screenshots:



It also derailed me, just like yesterday.

Another interesting point, related to this bug: Note how the “Final date” has had one day subtracted between the first and second screenshots.

1 Like

I found this comment on the Trello Beeflat board:

user changed their rate and runits at the same time and wound up with their road getting all properly adjusted except for the final row. we submit runits change first and then rate iff runits is successful. it looks like maybe they gave a rate in terms of weekly rate-units, while also submitting a runits change from weekly -> daily. so, this is technically user error, but broke in a bad way, and it is kind of ambiguous – maybe only ambiguous if you think about it too hard.

is there anything we can do to clear that ambiguity and rescue users from badly borking roads.

(With accompanying diagram that looks just like mine above.)

If I may object: I don’t think this is user error. There is no reason on earth to think that, if I want to go from 5 units a week to 1 unit a day, I can’t make that change directly: change 5 to 1 in the rate box, and change per week to per day in the units box, and then click Update.

I think it’s kind of crazy to expect users to understand how it works under the hood. “Okay, if I want to go from 5 a week to 1 a day, I first need to change the 5 to… let me calculate that… uh, 0.71 a day, so let’s put in 0.71 and click Update… okay, now let’s change to per day and click Update… okay, now I’ve MANUALLY CONVERTED MY EXISTING RATE IN MY OWN FUCKING HEAD AND WALKED BEEMINDER THROUGH IT STEP BY STEP. Now I can finally put 1 in for the daily rate.” (*) That’s… yeah.

What looks like at least part of the problem, to me, is that Beeminder is changing the road from the last time the road changed somewhere back in the past. In my last example above, that was September 16. So instead of changing my road rate starting a week from now, Beeminder changed it retroactively from September 16, aka six weeks ago. That seems like erroneous behavior.

I may totally be missing something (and probably am, because you guys are very smart cookies), but shouldn’t Beeminder be adding another row with a date seven days from today to close out the old rate and mark the start of the new one at the current akrasia horizon? EDIT: This was a display update misunderstanding; despite telling me the change succeeded and updating the final line rate in the road editor, BM didn’t actually update the display of the entire road editor. I didn’t see that until I revisited the goal from the dashboard. A new row was added to reflect a rate change starting at the akrasia horizon, but it uses the wrong rate. See my post below.

Judging by the before and after road editor screenshots above, the rate unit (runit) is an internal thing, but BM does remember that it used to be different (otherwise I’d expect the road editor to have updated all the old rates to be daily ones, but they’re still at their weekly values). EDIT: I just went into my goal again, some hours later, and now the road editor values have all updated to daily equivalents, aside from some extraneous added things that seem wrong (see my post below).

(*) This does appear to be what you have to do, however. After the snafus on the two test-case goals, I changed a third one piecewise. Starting from 3 per week, I changed to 0.6 per week (+) (so changed rate only) and Updated. I then changed to 0.6 per day (so changed runit only) and Updated. This worked to change the rate from 3 per week to 0.6 per day without derailing me or borking the road.

(+) This eliminates one step of my frustrated example in the main post; rather than go from 3 per week to the equivalent per day, then the desired daily rate, I can of course go straight to the desired rate, then change to daily units. (I know 3/wk != 0.6/day, but the goal was to get weekends off, so it’s really 3/5days = 0.6/day.)

1 Like

Regarding the ambiguity of having the rate and the rate units both adjustable beside one another, and how to interpret that (as noted on this Trello Beeflat card), here’s what I think “obvious” behavior would be. (YMMV and it might be great to hear what other users think “obvious” behavior should be.)

  • If I change only the rate, then click Update: change the rate to the new value at the same runit frequency. For example, if I had 5 per week and I change the rate to 7, show me 7 per week. Now, ask me to confirm.

  • If I change only the runit, then click Update: change the runit and autocalculate and populate the rate field with the corresponding “same rate” value. For example, if I had 5 per week and I’ve now changed to per day, show me 0.71 per day. Now, ask me to confirm. (*)

  • If I change both rate and runit, then click Update: assume I want the new rate in the new unit. So if I had 5 per week and I’ve now changed to 1 per day, show me 1 per day and ask me to confirm.

I think the asking to confirm is crucial to lowering the number of support requests you get to fix people’s borked roads. Show the user what Beeminder thinks they’ve asked for, update to that assumption if they click Yes, and throw away the changes altogether if they click No.

Whatever behavior Beeminder actually exhibits, that should be clearly described in multiple places: hovertext in the Commit To box would be an excellent one.

(*) Note that current behavior is that only the runit changes; for example, if I have 0.6 per week and I change only the runit to per day, the new rate used is 0.6 per day.

1 Like

So, some hours later, I revisited this goal and looked at the road editor and… I think there’s a general updating of current state display issue in the new design. I’ve noted it before in other places (such as changing the “Commit To” goal date and having it look fine after update, but a day off when I go back in; note this isn’t the subtract-one problem I’m referring to now, but the showing-the-current-state disparity).

To wit, my road editor showed me this right after Beeminder updated my new “Commit To” rate and runits (this is the AFTER picture from my post above):

And this is what it’s showing me now:

Note that all the old values have been converted from weekly rates to daily rates now. That’s cool. Not so cool is the addition of three new rows with erroneous data. Looks like this is where the graph is getting borked. (Note there was a fourth row also added, which I deleted: 10-27 date, 71 total. Nothing happened to the graph when I deleted it.)

None of those three rows seems correct. Two of them seem extraneous (the 10-27 row and one of the 11-03 rows)—but maybe I’m overlooking something? The obviously necessary row (to tell BM that the old rate applies through the akrasia horizon (11-03)) seems to be using the wrong rate, however. Shouldn’t it be the old daily rate of 0.7142…, not the new daily rate of 1? (And the one with 5 seems way off.)

For the record, deleting the 10-27 date, 5 rate row (and keeping the 10-27 date, 71 total row) appears to have solved the problem:


(Hi. Yes, it’s me again, with more data/info/blather. For comparison, I am possibly the only programmer in the history of programming who was ever told she overcommented her code.)

If you look closely here, you can see that BM has actually updated the old rate (5 per week, which is equivalent to 0.71 per day) to the new rate (1 per day, which is equivalent to 7 per week) inside the akrasia horizon:

Which is what the 11-03 road editor line of 1 is doing. So that, at least, now makes sense. (I still don’t understand what the second 11-03 line with a rate of 5 does; possibly it’s ignored? I’m also unclear on why there are two 09-16 lines.)

(The 10-28 and 10-30 lines are “Weekend Off”—note that the 10-28 line is also using the new 1 per day rate.)

Maybe this is intended behavior, but I’m guessing it isn’t? Since restricting rate changes to beyond the akrasia horizon is a pretty major Beeminder principle.


Hi @grayson! We are actually discussing this right now on slack, and these posts have been tremendously helpful in realizing what’s going on and in deciding what to do about it :slight_smile:


Okay so now when you change the rate units (per day, week etc) it changes the rate as well. So no more math in your head! Agreed that that’s not really fairly called user error, btw.

We’re still not out of the confusion woods yet, though, since as you point out, after you make that change using the Commit To form, the road editor will be out of date until you reload the page. It will be a decent chunk of work to have it update on the fly… we might want to just put a warning on it if it’s out of date.

We also moved the road editor from the commitment tab to Settings, since there are quite a few ways still to completely break your graph by messing with it, so this way it’s a little more hidden from newbees.


Thanks for the updates, Andy! I really appreciate it.

I don’t think Settings is a bad place for it, but isn’t the road editor a power-user feature? Newbees won’t encounter it unless they sign up for Bee Plus. And if you’re signing up for Bee Plus, there’s a good chance the road editor is something you deliberately want.

I think that’s a great idea.

Given the caveat that I know only enough about this to make me dangerous and probably make me sound stupid: can you force a refresh in the page’s html code? Or use a timeout value that tells the browser to always ignore the page in cache (like the Apache mod_expires directives you can add to your .htaccess, only on the server side instead of the client side it’s all server side, just .htaccess is for lowly users without access to main config files)? I know the point of Ajax is to avoid whole-page refreshes but given the situation, maybe it’s a penalty worth paying.

And now back to our regularly scheduled episode of okay-she’s-a-little-helpful-but-christ-she’s-wordy. No, wait, I think we’re just back after a commercial break. She was totally already being overly wordy above the horizontal rule.

I have a theory on what’s borking the road when you change both the rate and runit simultaneously.

All those duplicate-date rows I mentioned in previous posts? It appears that BM is only using the first one for a given date, and ignoring any later ones. That’s why, when I removed the 10-27 date, 71 total row, it didn’t affect the (then still-borked) graph: the 10-27 date, 5 rate row came first. And that one was the culprit making the graph shoot off skyward.

The proper row to signal the end of the old rate/runit was the 10-27 date, 71 total. But for some reason BM also added the 10-27 date, 5 rate row.

BM also added duplicate akrasia-horizon rows for 11-03. This time, the rate-of-1 row came before the rate-of-5 row, so the displayed behavior looks correct. But it seems to me that the rate-of-5 row shouldn’t be there in the first place.

So my guess is that that’s where your error is: in whatever in the code is adding that duplicate row.


That’s a good point about it being only for Bee Plus and higher… though there are probably some people who sign up for that for some other reason, have no idea what the road editor is, and then see a shiny thing and break their graph… but yeah might have been a little quick on the trigger there.

Will add the warning soon. The more specific explanation is that when we submit the Commit To form for the rate, we do it with javascript (AJAX), and therefore the page doesn’t reload after the goal is updated. We’d have to write javascript to go in and update the road editor form with the new data, rather than build the updated form on the server (which is easy because the code to do that is already written). Not sure if that helps or just adds to confusion :slight_smile:

And I’m still noodling over what could be going on with the dupe rows - my gut suspicion is it’s something to do with having weekends off on this goal, but I haven’t tested that hypothesis yet.

Thanks again for delivering useful debugging information along with comic genius.


Definitely helpful! Thanks for taking the time to explain it—I know you have tons on your plate.

My thinking was that to avoid the complexity of writing the new javascript, you could just kludge a single-line “oh ALL RIGHT refresh the whole stinkin’ page then” in html (or whatever) to temporarily solve all the display-mismatch problems. Not that it’s elegant, but it would solve the problem for now, pending some future day in which you guys don’t have enough to do. (Where’s the emoticon for Pipe Dreams? Here, I’ll just go with this symbol of the 1960s :peace:)

I don’t think it does: my second test goal didn’t enable Weekends Off at first. The road wonkiness, including duplicate rows, was all due to changing both rate and runit at the same time in the “Commit To” box. (Sorry, I know I made that connection first, when I very bad-doggy did both that and Weekends Off for the first goal and misinterpreted the culprit in my initial post.)


Yes please, hard refresh in this one case is way better than the road editor showing incorrect data. (You can limit it to users who actually have access to the road editor.)

1 Like