Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[usage] show sum of usage not balance #13222

Merged
merged 1 commit into from
Sep 23, 2022

Conversation

svenefftinge
Copy link
Member

Description

On the usage view we now only show usage and the sum is the sum of all usage in the selected period.

Related Issue(s)

fixes #13067

How to test

Release Notes

NONE

Documentation

Werft options:

  • /werft with-local-preview
    If enabled this will build install/preview
  • /werft with-preview
  • /werft with-payment
  • /werft with-integration-tests=all
    Valid options are all, workspace, webapp, ide

@svenefftinge svenefftinge requested a review from a team September 23, 2022 06:12
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label Sep 23, 2022
@svenefftinge
Copy link
Member Author

svenefftinge commented Sep 23, 2022

/werft run

👍 started the job as gitpod-build-sefftinge-usage-show-the-sum-of-13067.1
(with .werft/ from main)

Copy link
Member

@easyCZ easyCZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - non-backwards compatible proto change

Comment on lines +165 to 168
if creditCents.ToCredits() <= 0 {
// account has no debt, do nothing
return nil, nil
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're here, we could also change the logic to do creditCents <= 0 because the Credits conversion only multiplies by a 100, which won't change the polarity

// the amount of credits the given account (attributionId) had at the end of the requested period
double credit_balance_at_end = 4;
// the amount of credits the given account (attributionId) has used during the requested period
double credits_used = 3;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not backwards compatible. The rollout order between server and usage is undefined, and therefore you're not guaranteed it won't try to pass this value.
Please mark credit_balance_at_start as either reserved or [deprecated=true] and add a new field with ID 5.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm aware this is not compatible.
I expect the friction this would cause minimal (very short period between the two component deploys, where errors would be thrown for a feature that is not used by users, yet) compared to the extra turnaround.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you expect any serious issues here or is this more a matter of principles?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requests could actually fail to serialize on the usage component and return Unknown error. This is because each field is looked up by their index field. Here, it's kind of lucky that the field is the same type, but the removal of a field (4) would cause issues for the serializer as it expects there to be a field with index 4 (even if it's empty).

Even if we're happy with a temporary issue, we as a team (and organization) need to do better here in order to improve our reliability. It's a matter of getting into the habit of thinking (and dealing) with these else we're gonna struggle to uphold our standards as the systems grow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I agree with the principle behind it. Not sure going through unnecessary ceremony is helpful. I think acknowledging this explicitly, which is what we are doing here, is great. IMHO it is actually even better than blindly following a certain protocol, because we are talking about the real impact. FWIW just making it technically compatible wouldn't help users, because on the client side there would be a different result unless I roll out a full compatibility mode, which I would be happy to do if it was worth it.

Copy link
Member

@easyCZ easyCZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving, as you are comfortable with the incompatibility introduced.

@roboquat roboquat merged commit 5670a55 into main Sep 23, 2022
@roboquat roboquat deleted the sefftinge/usage-show-the-sum-of-13067 branch September 23, 2022 08:03
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels Sep 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed Change is completely running in production release-note-none size/L team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[usage] Show the sum of usage, not the balance
3 participants