feat: no default objects + staking changes

[cgilbe27]

Summary by CodeRabbit

• Refactor
  • Simplified and streamlined various test functions by removing optional parameters, enhancing reliability and maintenance.
  • Updated import statements to align with new testing requirements and features.
  • Replaced delegations related logic with featureFlags handling in the queryBatchHandler function for improved functionality.

[coderabbitai]

Walkthrough

The recent updates refine the GraphQL schema, emphasizing staking features by removing outdated elements like delegations and enhancing query handling. These changes streamline interactions, focusing on explicit data management through adjusted function signatures and the removal of default parameters.

Changes

Files	Change Summary
src/gql/heart-monitor/heart-monitor.test.ts, src/gql/query/index.ts	Refocused on staking, updating imports and declarations, shifting away from delegations.
src/gql/query/* except communityPool.ts	Standardized function signatures, removed unused defaults, and required fields parameters.
src/gql/subscription/*	Improved subscription functions by requiring fields parameters and enhancing parameter ordering.
src/gql/query/communityPool.ts	Enhanced default handling in communityPoolQueryString.
src/gql/utils/defaultObjects.ts	Added new default objects for staking functionalities.

🐰✨
In the land of code where the data hops around,
A rabbit tweaked the queries, less clutter found.
Staking is the star, old fields take a bow,
Cleaner, leaner calls, the future is now!
Hop along, dear data, in your streamlined groove,
With every commit, our system improves! 🌟🚀

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

Out of diff range and nitpick comments (2)

src/gql/query/distributionCommissions.ts (1)

Line range hint 19-29: Consider removing default value assignments within distributionCommissionsQueryString to align with the PR's objective of explicit data handling.

-  if (!args.limit) args.limit = 100
-  if (!args.order_desc) args.order_desc = true
-  if (!args.order_by) args.order_by = GQLDistributionCommissionOrder.GQLValidatorAddress

src/gql/utils/defaultObjects.ts (1)

Line range hint 58-58: Add missing properties creation_block and self_delegation to defaultValidator to match the GQLValidator type.

+  creation_block: defaultBlock,
+  self_delegation: 0,

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between dabe094 and 2448e4a.

Files selected for processing (28)

• src/gql/heart-monitor/heart-monitor.test.ts (37 hunks)
• src/gql/heart-monitor/heart-monitor.ts (5 hunks)
• src/gql/query/communityPool.ts (2 hunks)
• src/gql/query/distributionCommissions.ts (3 hunks)
• src/gql/query/featureFlags.ts (2 hunks)
• src/gql/query/governance.ts (4 hunks)
• src/gql/query/ibc.ts (4 hunks)
• src/gql/query/index.ts (2 hunks)
• src/gql/query/inflation.ts (4 hunks)
• src/gql/query/markPriceCandles.ts (2 hunks)
• src/gql/query/oracle.ts (4 hunks)
• src/gql/query/perp.ts (4 hunks)
• src/gql/query/proxies.ts (2 hunks)
• src/gql/query/spotLpPositions.ts (2 hunks)
• src/gql/query/spotPoolCreated.ts (2 hunks)
• src/gql/query/spotPoolExited.ts (2 hunks)
• src/gql/query/spotPoolJoined.ts (2 hunks)
• src/gql/query/spotPoolSwap.ts (2 hunks)
• src/gql/query/spotPools.ts (2 hunks)
• src/gql/query/staking.ts (1 hunks)
• src/gql/query/stats.ts (4 hunks)
• src/gql/query/users.ts (2 hunks)
• src/gql/query/wasm.ts (4 hunks)
• src/gql/subscription/markPriceCandlesSubscription.ts (1 hunks)
• src/gql/subscription/oraclePricesSubscription.ts (2 hunks)
• src/gql/subscription/perpMarketSubscription.ts (2 hunks)
• src/gql/subscription/perpPositionsSubscription.ts (2 hunks)
• src/gql/utils/defaultObjects.ts (2 hunks)

Files skipped from review due to trivial changes (2)

• src/gql/query/markPriceCandles.ts
• src/gql/query/perp.ts

Additional Context Used

GitHub Check Runs (1)

checkout_cache_install_build_test failure (6)

src/gql/utils/defaultObjects.ts: [failure] 58-58:
Type '{ commission_update_time: string; commission_rates: { max_change_rate: number; max_rate: number; rate: number; }; delegator_shares: number; description: { details: string; identity: string; moniker: string; security_contact: string; website: string; }; ... 6 more ...; unbonding_time: string; }' is missing the following properties from type 'GQLValidator': creation_block, self_delegation

Additional comments not posted (75)

src/gql/query/proxies.ts (2)

16-21: Explicit requirement of fields parameter enhances clarity and robustness in data handling.

---

27-27: Change in function signature to require fields parameter aligns with the overall PR objectives and improves explicitness in data handling.

src/gql/query/featureFlags.ts (2)

16-21: Explicit requirement of fields parameter enhances clarity and robustness in data handling.

---

27-27: Change in function signature to require fields parameter aligns with the overall PR objectives and improves explicitness in data handling.

src/gql/query/index.ts (1)

21-21: Addition of ./staking to exports aligns with the PR's focus on enhancing staking functionalities.

src/gql/query/users.ts (2)

19-28: Explicit requirement of fields parameter and effective handling of default values enhance clarity and robustness in data handling.

---

36-36: Change in function signature to require fields parameter aligns with the overall PR objectives and improves explicitness in data handling.

src/gql/subscription/markPriceCandlesSubscription.ts (2)

13-19: Explicit requirement of fields parameter enhances clarity and robustness in data handling for subscriptions.

---

26-27: Change in function signature to require fields parameter and optionally take a client aligns with the overall PR objectives and improves explicitness in data handling for subscriptions.

src/gql/query/spotPools.ts (2)

19-28: Explicit requirement of fields parameter and effective handling of default values enhance clarity and robustness in data handling.

---

36-36: Change in function signature to require fields parameter aligns with the overall PR objectives and improves explicitness in data handling.

src/gql/subscription/perpMarketSubscription.ts (2)

17-23: Explicit requirement of fields parameter enhances clarity and robustness in data handling for subscriptions.

---

30-31: Change in function signature to require fields parameter and optionally take a client aligns with the overall PR objectives and improves explicitness in data handling for subscriptions.

src/gql/subscription/perpPositionsSubscription.ts (2)

17-19: Explicit requirement of fields parameter enhances clarity and robustness in data handling for subscriptions.

---

23-24: Change in function signature to require fields parameter and optionally take a client aligns with the overall PR objectives and improves explicitness in data handling for subscriptions.

src/gql/subscription/oraclePricesSubscription.ts (2)

17-17: Explicitly requiring fields parameter enhances clarity and robustness in data handling.

---

30-31: Proper handling of optional client parameter allows for flexible usage scenarios.

src/gql/query/spotPoolSwap.ts (2)

19-22: Setting default values within the function enhances control and explicitness over query parameters.

---

36-36: Requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

src/gql/query/communityPool.ts (2)

19-23: Setting default values within the function enhances control and explicitness over query parameters.

---

36-36: Requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

src/gql/query/spotPoolExited.ts (2)

19-22: Setting default values within the function enhances control and explicitness over query parameters.

---

36-36: Requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

src/gql/query/spotPoolJoined.ts (2)

19-22: Setting default values within the function enhances control and explicitness over query parameters.

---

36-36: Requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

src/gql/query/spotLpPositions.ts (2)

19-22: Setting default values within the function enhances control and explicitness over query parameters.

---

36-36: Requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

src/gql/query/spotPoolCreated.ts (2)

19-22: Setting default values within the function enhances control and explicitness over query parameters.

---

36-36: Requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

src/gql/query/wasm.ts (2)

23-23: Requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

---

47-47: Explicitly requiring fields parameter ensures all necessary fields are explicitly passed, aligning with PR objectives.

src/gql/query/distributionCommissions.ts (1)

37-37: Changes in distributionCommissions function look good and align with the PR's objectives.

src/gql/query/ibc.ts (2)

Line range hint 26-46: Changes in ibcQueryString function look good and align with the PR's objectives of explicit data handling.

---

62-62: Changes in ibc function look good and align with the PR's objectives.

src/gql/query/oracle.ts (2)

29-29: Changes in oracleQueryString function look good and align with the PR's objectives of explicit data handling.

---

65-65: Changes in oracle function look good and align with the PR's objectives.

src/gql/query/inflation.ts (2)

31-31: Changes in inflationQueryString function look good and align with the PR's objectives of explicit data handling.

---

78-78: Changes in inflation function look good and align with the PR's objectives.

src/gql/query/governance.ts (2)

33-33: Changes in governanceQueryString function look good and align with the PR's objectives of explicit data handling.

---

80-80: Changes in governance function look good and align with the PR's objectives.

src/gql/query/stats.ts (2)

49-49: Changes in GQLStatsQueryString function look good and align with the PR's objectives of explicit data handling.

---

140-140: Changes in stats function look good and align with the PR's objectives.

src/gql/query/staking.ts (2)

39-104: Changes in GQLStakingQueryString function look good and align with the PR's objectives of explicit data handling.

---

107-107: Changes in staking function look good and align with the PR's objectives.

src/gql/heart-monitor/heart-monitor.ts (7)

94-97: Addition of staking-related types and function.

This addition aligns with the PR's objective to enhance staking functionalities.

---

107-107: Ensure explicit field specification in communityPool method.

Verification successful

---

The verification process has successfully identified two instances where the communityPool method is called within the TypeScript files of the project. Both instances explicitly specify the fields parameter, which aligns with the requirement stated in the review comment to ensure explicit field specification.

• In src/gql/heart-monitor/heart-monitor.ts, the method is called with args, this.gqlEndpt, and fields.
• In src/gql/heart-monitor/heart-monitor.test.ts, the method is called within a test environment with args and fields.

These findings confirm that the method calls adhere to the new changes requiring explicit field specification.

Conclusion:
All calls to the communityPool method in the TypeScript files explicitly specify the fields parameter as required. No issues were found regarding the adherence to the new method signature.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify that all calls to `communityPool` method explicitly specify fields as per new changes.

# Test: Search for the function usage. Expect: No occurrences of calls without field specification.
rg --type typescript $'communityPool\\('

Length of output: 75

---

---

Script:

#!/bin/bash
# Description: Verify that all calls to `communityPool` method explicitly specify fields as per new changes.

# Test: Search for the function usage. Expect: No occurrences of calls without field specification.
rg --type ts $'communityPool\\('

Length of output: 227

---

116-116: Addition of featureFlags method to handle feature flags.

This method supports the new feature flags functionality, enhancing configurability.

---

213-217: Addition of staking method in the interface.

This method supports the new staking functionality, aligning with the PR's objectives.

---

265-270: Ensure explicit field specification in communityPool method implementation.

Verification successful

---

The verification process has confirmed that all calls to the communityPool method in the codebase explicitly specify the fields parameter. This aligns with the requirements mentioned in the review comment. Both instances found in src/gql/heart-monitor/heart-monitor.ts and src/gql/heart-monitor/heart-monitor.test.ts include the args, this.gqlEndpt, and fields parameters in their calls to communityPool.

Conclusion:

• The implementation of the communityPool method correctly specifies the fields parameter in all its calls, as required.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify that all calls to `communityPool` method in implementation explicitly specify fields as per new changes.

# Test: Search for the function usage. Expect: No occurrences of calls without field specification.
rg --type typescript $'communityPool\\('

Length of output: 75

---

---

Script:

#!/bin/bash
# Description: Verify that all calls to `communityPool` method in implementation explicitly specify fields as per new changes.

# Test: Search for the function usage. Expect: No occurrences of calls without field specification.
rg --type ts $'communityPool\\('

Length of output: 227

---

273-273: Implementation of featureFlags method.

Proper implementation of the method to handle feature flags.

---

356-359: Implementation of staking method.

Proper implementation of the method to handle new staking functionalities.

src/gql/heart-monitor/heart-monitor.test.ts (24)

96-101: Addition of new constants and types for staking tests.

These additions are necessary for testing the new staking functionalities.

---

149-149: Modification in testCommunityPool to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

167-167: Modification in testDistributionCommissions to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

184-184: Addition of testFeatureFlags to test the new feature flags functionality.

This test ensures that the new feature flags functionality is working as expected.

---

204-204: Modification in testGovernance to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

283-283: Modification in testInflation to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

322-322: Modification in testMarkPriceCandles to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

359-359: Addition of testMarkPriceCandlesSubscription to test the new subscription functionality.

This test ensures that the new subscription functionality for mark price candles is working as expected.

---

428-428: Addition of testOraclePricesSubscription to test the new subscription functionality.

This test ensures that the new subscription functionality for oracle prices is working as expected.

---

452-452: Modification in testPerp to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

545-545: Addition of testPerpMarketSubscription to test the new subscription functionality.

This test ensures that the new subscription functionality for perpetual market data is working as expected.

---

612-612: Addition of testPerpPositionsSubscription to test the new subscription functionality.

This test ensures that the new subscription functionality for perpetual positions is working as expected.

---

654-654: Addition of testProxies to test the new proxies functionality.

This test ensures that the new proxies functionality is working as expected.

---

673-676: Addition of testQueryBatchHandler to test the new batch handler functionality.

This test ensures that the new batch handler functionality is working as expected.

---

700-700: Modification in testSpotLpPositions to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

721-721: Modification in testSpotPoolCreated to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

739-739: Modification in testSpotPoolExited to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

757-757: Modification in testSpotPoolJoined to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

775-775: Modification in testSpotPools to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

807-807: Modification in testSpotPoolSwap to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

826-826: Modification in testStats to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

848-851: Addition of testStaking to test the new staking functionality.

This test ensures that the new staking functionality is working as expected.

---

968-968: Modification in testWasm to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

---

999-999: Modification in testUsers to ensure explicit field specification.

This change aligns with the new requirement to explicitly specify fields in GraphQL queries.

[coderabbitai]

Actionable comments posted: 0

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 2448e4a and 575f02e.

Files selected for processing (1)

• src/gql/heart-monitor/heart-monitor.test.ts (39 hunks)

Additional comments not posted (31)

src/gql/heart-monitor/heart-monitor.test.ts (31)

87-92: Added new imports for feature flags and staking-related types and queries.

---

95-101: Introduced a new utility function checkNoFields to ensure certain fields are not present in objects. This is useful for testing the absence of fields in response objects.

---

140-140: Modified the testCommunityPool function to explicitly require the fields parameter, aligning with the removal of default objects in the system.

---

158-158: Updated the testDistributionCommissions function to explicitly require the fields parameter. This change is consistent with the overall PR goal of removing default objects.

---

175-175: Added a new test function testFeatureFlags to handle the testing of feature flags functionality. This addition is necessary due to the introduction of feature flags in the system.

---

195-195: Modified the testGovernance function to explicitly require the fields parameter, which is part of the broader changes to remove default objects.

---

236-236: Updated the testIbc function to explicitly require the fields parameter. This change supports the PR's objective of explicit field specification in GraphQL queries.

---

274-274: Modified the testInflation function to explicitly require the fields parameter, aligning with the removal of default objects.

---

300-300: Updated the testOracle function to explicitly require the fields parameter. This change is consistent with the PR's goal of removing default objects.

---

313-313: Modified the testMarkPriceCandles function to explicitly require the fields parameter, aligning with the removal of default objects.

---

334-343: Added handling for undefined client scenario in testMarkPriceCandlesSubscription. This is important for robustness, ensuring the system behaves correctly when the client is not properly initialized.

---

350-350: Updated the testMarkPriceCandlesSubscription function to explicitly require the fields parameter. This change supports the PR's objective of explicit field specification in GraphQL queries.

---

407-412: Added handling for undefined client scenario in testOraclePricesSubscription. This ensures that the system behaves correctly when the client is not properly initialized, which is crucial for robustness.

---

419-419: Updated the testOraclePricesSubscription function to explicitly require the fields parameter. This change is consistent with the PR's goal of removing default objects.

---

443-443: Updated the testPerp function to explicitly require the fields parameter. This change supports the PR's objective of explicit field specification in GraphQL queries.

---

524-529: Added handling for undefined client scenario in testPerpMarketSubscription. This is important for robustness, ensuring the system behaves correctly when the client is not properly initialized.

---

536-536: Updated the testPerpMarketSubscription function to explicitly require the fields parameter. This change is consistent with the PR's goal of removing default objects.

---

588-596: Added handling for undefined client scenario in testPerpPositionsSubscription. This ensures that the system behaves correctly when the client is not properly initialized, which is crucial for robustness.

---

603-603: Updated the testPerpPositionsSubscription function to explicitly require the fields parameter. This change supports the PR's objective of explicit field specification in GraphQL queries.

---

645-645: Added a new test function testProxies to handle the testing of proxy functionality. This addition is necessary due to the introduction of proxies in the system.

---

664-684: Added a new queryBatchHandler function to handle batch queries for community pool and feature flags. This function is crucial for handling multiple queries in a single call, improving efficiency.

---

691-691: Updated the testSpotLpPositions function to explicitly require the fields parameter. This change is consistent with the PR's goal of removing default objects.

---

712-712: Updated the testSpotPoolCreated function to explicitly require the fields parameter, aligning with the removal of default objects.

---

730-730: Updated the testSpotPoolExited function to explicitly require the fields parameter. This change supports the PR's objective of explicit field specification in GraphQL queries.

---

748-748: Updated the testSpotPoolJoined function to explicitly require the fields parameter. This change is consistent with the PR's goal of removing default objects.

---

766-766: Updated the testSpotPools function to explicitly require the fields parameter, aligning with the removal of default objects.

---

798-798: Updated the testSpotPoolSwap function to explicitly require the fields parameter. This change supports the PR's objective of explicit field specification in GraphQL queries.

---

817-817: Updated the testStats function to explicitly require the fields parameter, aligning with the removal of default objects.

---

839-906: Added a new testStaking function to handle the testing of staking functionality. This addition is necessary due to the introduction of staking in the system.

---

959-959: Updated the testWasm function to explicitly require the fields parameter. This change is consistent with the PR's goal of removing default objects.

---

990-990: Updated the testUsers function to explicitly require the fields parameter, aligning with the removal of default objects.

[coderabbitai]

Actionable comments posted: 0

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 575f02e and cefb814.

Files selected for processing (2)

• src/gql/utils/consts.test.ts (1 hunks)
• src/gql/utils/defaultObjects.ts (3 hunks)

Files skipped from review as they are similar to previous changes (1)

• src/gql/utils/defaultObjects.ts

Additional comments not posted (1)

src/gql/utils/consts.test.ts (1)

17-41: Ensure the new test for featureFlags is comprehensive.

Verification successful

---

The search results from the script indicate that the featureFlags are extensively tested across multiple files in the codebase, including heart-monitor.test.ts, heart-monitor.ts, and featureFlags.ts. The tests check for the presence of featureFlags in the response, validate its structure, and ensure that the query string and function handling are correctly implemented.

Given this comprehensive testing across different modules, it appears that the new test for featureFlags in consts.test.ts is part of a well-covered feature in the codebase. The tests in consts.test.ts are consistent with the testing patterns observed in other parts of the codebase, suggesting that the necessary aspects of featureFlags are indeed being tested.

Based on this information, the review comment concerning the comprehensiveness of the featureFlags test in consts.test.ts seems to be verified successfully.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify that the new test for `featureFlags` covers all necessary aspects.

# Test: Search for additional tests related to `featureFlags` in the test suite.
rg --type ts $'featureFlags'

Length of output: 2240

[coderabbitai]

Actionable comments posted: 0

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between cefb814 and 7e404cd.

Files selected for processing (1)

• jest.config.ts (1 hunks)

Files skipped from review due to trivial changes (1)

• jest.config.ts

[coderabbitai]

Actionable comments posted: 0

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 7e404cd and eef6b59.

Files selected for processing (2)

• src/gql/heart-monitor/heart-monitor.test.ts (39 hunks)
• src/gql/utils/defaultObjects.ts (3 hunks)

Files skipped from review as they are similar to previous changes (2)

• src/gql/heart-monitor/heart-monitor.test.ts
• src/gql/utils/defaultObjects.ts

[github-actions]

Lines	Statements	Branches	Functions
	90.25% (1009/1118)	72.02% (291/404)	76.41% (243/318)

[nibibot]

🎉 This PR is included in version 4.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀