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

feat: l2 metrics service #63

Merged
merged 3 commits into from
Sep 3, 2024
Merged

feat: l2 metrics service #63

merged 3 commits into from
Sep 3, 2024

Conversation

0xnigir1
Copy link
Collaborator

@0xnigir1 0xnigir1 commented Sep 2, 2024

🤖 Linear

Closes ZKS-228

Description

  • L2MetricsService implementation on metrics package
  • add zk provider method for fetching blocks range for a given L1 Batch

@0xnigir1 0xnigir1 requested review from 0xkenj1 and 0xyaco September 2, 2024 21:46
Copy link

linear bot commented Sep 2, 2024

0xyaco
0xyaco previously approved these changes Sep 3, 2024
Copy link
Collaborator

@0xyaco 0xyaco left a comment

Choose a reason for hiding this comment

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

Good to go!

Comment on lines +128 to +143
describe("getL1BatchBlockRange", () => {
it("should return the block range for the specified L1 batch number", async () => {
zkProvider = new ZKChainProvider(defaultRpcUrls, mockLogger, defaultMockChain);
const l1BatchNumber = 1000;
const blockRange: [number, number] = [5000, 6000];

vi.spyOn(zkProvider["zkClient"], "getL1BatchBlockRange").mockResolvedValue(blockRange);

const result = await zkProvider.getL1BatchBlockRange(l1BatchNumber);

expect(result).toEqual(blockRange);
expect(zkProvider["zkClient"].getL1BatchBlockRange).toHaveBeenCalledWith({
l1BatchNumber,
});
});
});
Copy link
Collaborator

Choose a reason for hiding this comment

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

Any non-happy paths worth testing?

Copy link
Collaborator

@0xkenj1 0xkenj1 left a comment

Choose a reason for hiding this comment

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

just a brief comment

} else if (isNativeError(error)) {
this.logger.error(error);
}
return undefined;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Following the way we are handling errors, for the rest of the methods. Should we throw here instead of returning undefined ? The lastVerifiedBlock is not an optional method on the front end

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this got me thinking tbh, should we actually return return value | undefined for all methods? like an error on L2 shouldn't break anything as it's like not having rpc urls wdyt?

0xkenj1
0xkenj1 previously approved these changes Sep 3, 2024
@0xnigir1 0xnigir1 dismissed stale reviews from 0xkenj1 and 0xyaco via 13c9021 September 3, 2024 18:55
@0xnigir1 0xnigir1 requested review from 0xkenj1 and 0xyaco September 3, 2024 18:56
@0xnigir1
Copy link
Collaborator Author

0xnigir1 commented Sep 3, 2024

as discussed offline @0xkenj1, we let the service consumer handle errors instead of returning undefined for consistency

Copy link
Collaborator

@0xkenj1 0xkenj1 left a comment

Choose a reason for hiding this comment

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

🚀

@0xnigir1 0xnigir1 merged commit d5b2901 into dev Sep 3, 2024
6 checks passed
@0xnigir1 0xnigir1 deleted the feat/l2-metrics-service branch September 3, 2024 19:35
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.

3 participants