Backfill counters have an issue

[travjenkins]

Bug Sometimes the backfill counter is getting changed in odd ways. Not 100% sure what the issue is but it seems like an off by one due to how the issue is showing up in history. However, some issues do not align with that so maybe that isn't it.

Expected They are incremented correctly

Screenshots N/A - contain sensitive information

Desktop (please complete the following information): N/A

Additional context N/A

[dyaffe]

Here are two observations that I've found when playing with this:

1. Clicking "backfill" then "refresh" will result in backfill counters being increased but the UI showing that a backfill won't happen based on the backfill checkboxes in the UI.
2. Double clicking a backfill counter enough times can result in it going up or down

It's possible that something else is also going on, but I can see this causing the behavior that the user observed. In this hypothetical scenario, they would have backfilled then refreshed and seen after the refresh that a backfill wasn't going to happen in the UI.

It doesn't exactly explain what we saw but enough refreshes and doubleclicks of backfill could get pretty close.

[kiahna-tucker]

Notes on two, potential safeguarding maneuvers that were previously discussed:

• Adding a numeric type guard to getBackfillCounter is a touch superfluous. The only way a backfill counter could be non-numeric would be to edit the specification on the server or a bug in the control plane that could be exploited by the CLI. These scenarios are highly unlikely.

• Stashing the live backfill counter for a given binding in client state does not prevent the original issue from occurring and evaluating the live backfill counter for each binding when setting the drafted backfill counter is not performant.