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

Support large metrics numbers #30

Open
wants to merge 8 commits into
base: development/1.1
Choose a base branch
from

Conversation

williamlardier
Copy link
Contributor

We use strings because the usual number type is too limited (up to ~9PB). using string is an efficient way to transmit the information, and later, in nodejs, to parse it as BigInt.

Returning actual number won't work if they exceed the Max Safe
Integer, which is aroung 9PB of "totalBytes", for example.

Issue: SCUBA-217
- Test with big numbers.
- Make the tests independent from order of execution.

Issue: SCUBA-217
@williamlardier williamlardier requested review from tmacro and dvasilas and removed request for tmacro January 16, 2025 15:57
Needed to know how to use BigInt.

Issue: SCUBA-217
- It won't return string, this will be handled by the program
  using the values.

Issue: SCUBA-217
@williamlardier williamlardier changed the base branch from development/1.0 to development/1.1 January 21, 2025 09:50
package.json Outdated Show resolved Hide resolved
src/client.ts Outdated Show resolved Hide resolved
src/client.ts Outdated
@@ -35,9 +35,20 @@ export type ScubaClientParameters = Omit<
auth?: ScubaAuth;
};

// API response types (with strings)
export type ScubaReturnedMetrics = {

Choose a reason for hiding this comment

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

nit: better convey this is the "wire" format : ScubaMetricsMessage or ScubaMetricsResponse ? or something like ScubaMetricsApi vs ScubeMetricsJson...

(ideally make it consistency between all types)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will use ScubaMetricsResponse, which is consistent with all other types: sometimes the client would also return the "Response" type, which is fine as long as we don't modify it, we can create other types later if we were to add more logic.

if ('error' in resource) {
return resource as GetMetricsBatchResponseResourceError;
}
return {

Choose a reason for hiding this comment

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

nit: to make the code more readable, this "conversion" could be a method of GetMetricsBatchScubaResponseResourceMetrics which does the conversion

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am removing the "as": it is not needed, TS is able to find the right type thanks to the if check already.

- We were passing a test on serialize() thank to the global
  toJSON defined in the test, yet during execution time, we
  would not be able to serialize. We cannot use toJSON globally
  in this repo, because it would affect all projects importing
  it, and eventually lead to unexpected side effects.

Issue: SCUBA-217
Issue: SCUBA-217
Issue: SCUBA-217
@williamlardier
Copy link
Contributor Author

williamlardier commented Jan 22, 2025

This PR was updated not to rely on toJSON: details in the commits. No logic was changed, but we explicitly convert to string when appropriate now. (in tests).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants