-
Notifications
You must be signed in to change notification settings - Fork 276
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
Add a floor of zero to transaction report counts #2074
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 files reviewed, 2 unresolved discussions (waiting on @jianglai)
core/src/main/resources/google/registry/reporting/icann/sql/cloud_sql_transaction_counts.sql
line 50 at r1 (raw file):
tld, report_field AS field, -- See b/290228682, there are edge cases in which the net_renew would be negative when
This kind of information should be in the PR/commit description too.
core/src/main/resources/google/registry/reporting/icann/sql/cloud_sql_transaction_counts.sql
line 51 at r1 (raw file):
report_field AS field, -- See b/290228682, there are edge cases in which the net_renew would be negative when -- a domain is cancelled by superusers during ARGP. The correct thing to do is attribute
It's not just the autorenew grace period, it's the renew grace period as well, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @CydeWeys)
core/src/main/resources/google/registry/reporting/icann/sql/cloud_sql_transaction_counts.sql
line 50 at r1 (raw file):
Previously, CydeWeys (Ben McIlwain) wrote…
This kind of information should be in the PR/commit description too.
Done.
core/src/main/resources/google/registry/reporting/icann/sql/cloud_sql_transaction_counts.sql
line 51 at r1 (raw file):
Previously, CydeWeys (Ben McIlwain) wrote…
It's not just the autorenew grace period, it's the renew grace period as well, right?
It would be any cancellation that happens during a corresponding grace period, if the cancellation is done by a different registrar other than the owning one (the one associated with cancellable action with the grace period). In practice I think only superuser would be able to do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jianglai)
core/src/main/resources/google/registry/reporting/icann/sql/cloud_sql_transaction_counts.sql
line 51 at r1 (raw file):
Previously, jianglai (Lai Jiang) wrote…
It would be any cancellation that happens during a corresponding grace period, if the cancellation is done by a different registrar by the owning one (the one associated with cancellable action with the grace period). In practice I think only superuser would be able to do that.
Right, so say it's any grace period (such as renew grace periods), rather than only calling out the autorenew grace period.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @CydeWeys)
core/src/main/resources/google/registry/reporting/icann/sql/cloud_sql_transaction_counts.sql
line 51 at r1 (raw file):
Previously, CydeWeys (Ben McIlwain) wrote…
Right, so say it's any grace period (such as renew grace periods), rather than only calling out the autorenew grace period.
I mentioned it at the end of the paragraph (after the last update). Here I'm calling out on the specific incident that led to this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jianglai)
core/src/main/resources/google/registry/reporting/icann/sql/cloud_sql_transaction_counts.sql
line 51 at r1 (raw file):
Previously, jianglai (Lai Jiang) wrote…
I mentioned it at the end of the paragraph (after the last update). Here I'm calling out on the specific incident that led to this change.
Guess who missed "Show full diff" :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jianglai)
See b/290228682, there are edge cases in which the net_renew would be negative when a domain is cancelled by superusers during renew grace period. The correct thing to do is attribute the cancellation to the owning registrar, but that would require changing the owing registrar of the the corresponding cancellation DomainHistory, which has cascading effects that we don't want to deal with. As such we simply floor the number here to zero to prevent any negative value from appearing, which should have negligible impact as the edge cage happens very rarely, more specifically when a cancellation happens during grace period by a registrar other than the the owning one. All the numbers here should be positive to pass ICANN validation.
The SQL statement was incorrectly flooring to zero one layer too deep, which was negating all negative transaction report rows (which occur most frequently when a domain in the autorenew grace period is deleted). I've changed it so that it now only floors to zero at the report level, which still solves the issue reported in http://b/290228682 but whose original fix caused the issue http://b/344645788 This bug was introduced in google#2074 I tested this by running the new query against the DB for 2024 Q4 using the registrar that was having issues and confirmed that the total renewal numbers for .app now match with the sum total of what we invoiced for the last three months of 2024.
The SQL statement was incorrectly flooring to zero one layer too deep, which was negating all negative transaction report rows (which occur most frequently when a domain in the autorenew grace period is deleted). I've changed it so that it now only floors to zero at the report level, which still solves the issue reported in http://b/290228682 but whose original fix caused the issue http://b/344645788 This bug was introduced in google#2074 I tested this by running the new query against the DB for 2024 Q4 using the registrar that was having issues and confirmed that the total renewal numbers for .app now match with the sum total of what we invoiced for the last three months of 2024.
The SQL statement was incorrectly flooring to zero one layer too deep, which was negating all negative transaction report rows (which occur most frequently when a domain in the autorenew grace period is deleted). I've changed it so that it now only floors to zero at the report level, which still solves the issue reported in http://b/290228682 but whose original fix caused the issue http://b/344645788 This bug was introduced in google#2074 I tested this by running the new query against the DB for 2024 Q4 using the registrar that was having issues and confirmed that the total renewal numbers for .app now match with the sum total of what we invoiced for the last three months of 2024.
See b/290228682, there are edge cases in which the net_renew would be negative when
a domain is cancelled by superusers during renew grace period. The correct thing
to do is attribute the cancellation to the owning registrar, but that would require
changing the owing registrar of the the corresponding cancellation DomainHistory,
which has cascading effects that we don't want to deal with. As such we simply
floor the number here to zero to prevent any negative value from appearing, which
should have negligible impact as the edge cage happens very rarely, more specifically
when a cancellation happens during grace period by a registrar other than the the
owning one. All the numbers here should be positive to pass ICANN validation.
This change is