-
Notifications
You must be signed in to change notification settings - Fork 10
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
Derive the session.id
/order_number
from the upload.id
#720
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #720 +/- ##
==========================================
- Coverage 98.07% 90.63% -7.44%
==========================================
Files 434 434
Lines 36734 36673 -61
==========================================
- Hits 36027 33240 -2787
- Misses 707 3433 +2726
Flags with carried forward coverage won't be shown. Click here to find out more.
|
❌ 8 Tests Failed:
View the top 3 failed tests by shortest run time
To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard |
Test Failures Detected: Due to failing tests, we cannot provide coverage reports at this time. ❌ Failed Test Results:Completed 1684 tests with View the full list of failed testspytest
|
❌ 8 Tests Failed:
View the top 3 failed tests by shortest run time
To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard |
The problem here is that `order_number` is a 32-bit signed int (effectively 31-bit), and duplicating the `reports_upload.id` into it does not work, as that value already exceeds 31-bits in production. This tries to work around that problem by arranging that number to occupy bits 12-28.
1e40b96
to
cdf4bba
Compare
This re-applies #713, which was reverted previously, as production
upload.id
exceed the bit width ofupload.order_number
.The problem was that
order_number
is a 32-bit signed int (effectively 31-bit),and duplicating the
reports_upload.id
into it does not work, as that value already exceeds 31-bits in production.This tries to work around that problem by deriving the
order_number
/session.id
like so:upload.id
order_number
This way, the derived ID should not collide with a carry-forwarded session with
order_number
s up to 12 bits.And the final derived/deterministic
order_number
is also below the 32 (effectively 31) bit threshold.