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

[BUG2-156] Only return recent best effort canceled orders. #2716

Merged
merged 9 commits into from
Feb 7, 2025

Conversation

vincentwschau
Copy link
Contributor

@vincentwschau vincentwschau commented Feb 5, 2025

Changelist

Only return best effort canceled orders within the last 20 blocks when fetching orders for subaccount channel subscriptions.
Update order store to allow querying for orders with goodTilBlock after a given block height, and update comlink to take in the same parameter.

Test Plan

Unit tests.

Author/Reviewer Checklist

  • If this PR has changes that result in a different app state given the same prior state and transaction list, manually add the state-breaking label.
  • If the PR has breaking postgres changes to the indexer add the indexer-postgres-breaking label.
  • If this PR isn't state-breaking but has changes that modify behavior in PrepareProposal or ProcessProposal, manually add the label proposal-breaking.
  • If this PR is one of many that implement a specific feature, manually label them all feature:[feature-name].
  • If you wish to for mergify-bot to automatically create a PR to backport your change to a release branch, manually add the label backport/[branch-name].
  • Manually add any of the following labels: refactor, chore, bug.

Summary by CodeRabbit

  • New Features

    • Introduced new order filtering options allowing users to narrow down orders based on numerical and timestamp criteria.
    • Enhanced subscription responses to improve clarity by refining the set of order statuses shown.
  • Tests

    • Expanded test coverage to validate the updated filtering logic and ensure accurate order retrieval.
  • Documentation

    • Updated API documentation and endpoint specifications to include the new filtering parameters.

@vincentwschau vincentwschau requested a review from a team as a code owner February 5, 2025 17:44
Copy link
Contributor

coderabbitai bot commented Feb 5, 2025

Walkthrough

This pull request introduces two new filtering parameters—goodTilBlockAfter and goodTilBlockTimeAfter—across several modules. The changes modify the database query logic, API endpoints, type declarations, and subscription handling. Updates include extending the findAll function and its tests in the Postgres module, enhancing the orders API documentation and Swagger definitions, and revising the orders controller logic. Additionally, the subscription layer tests and logic have been adjusted to reflect new URL patterns and response structures, while also refining order status handling.

Changes

Files Change Summary
indexer/packages/postgres/{__tests__/stores/order-table.test.ts, src/stores/order-table.ts, src/types/query-types.ts} Added filtering logic for goodTilBlockAfter and goodTilBlockTimeAfter in the order table queries; updated function signatures, test cases, enum values, and interface definitions.
indexer/services/comlink/{__tests__/controllers/api/v4/orders-controller.test.ts, public/api-documentation.md, public/swagger.json, src/controllers/api/v4/orders-controller.ts, src/types.ts} Integrated the new filtering parameters into orders endpoints; updated controller methods, tests, API docs, Swagger definitions, and request interfaces to support advanced time and block-based filtering.
indexer/services/socks/{__tests__/lib/subscriptions.test.ts, src/lib/subscription.ts} Adjusted subscription URL patterns and the initial message structure; updated subscription logic to refine order status handling and data retrieval (including axios-based block height checks), incorporating filtering conditions.

Sequence Diagram(s)

Order Retrieval Flow

sequenceDiagram
    participant Client
    participant API
    participant OrdersController
    participant OrderStore
    Client->>API: GET /orders (with filtering params)
    API->>OrdersController: Forward request
    OrdersController->>OrderStore: Call findAll(goodTilBlockAfter, goodTilBlockTimeAfter)
    OrderStore-->>OrdersController: Return filtered orders
    OrdersController-->>API: Send orders response
    API-->>Client: Deliver response
Loading

Subscription Data Retrieval Flow

sequenceDiagram
    participant Subscriber
    participant SubscriptionService
    participant Axios
    Subscriber->>SubscriptionService: Subscribe for order updates
    SubscriptionService->>Axios: Request orders (with block height filtering)
    Axios-->>SubscriptionService: Return order data and BEST_EFFORT_CANCELED orders
    SubscriptionService-->>Subscriber: Send combined subscription response
Loading

Possibly related PRs

  • [TRA-568] Initial vault PnL endpoints. #2121: The changes in the main PR, which enhance the findAll method in the OrderTable module with new filtering parameters, are related to the modifications in the retrieved PR that also introduce new parameters for filtering in the context of vault PnL endpoints, specifically the goodTilBlockAfter parameter. Both PRs involve similar enhancements to filtering logic within their respective modules.

Suggested reviewers

  • tqin7

Poem

I’m a rabbit with hops so light,
Code carrots now shine bright.
Filtering orders by block and time,
Makes our queries simply sublime.
Tests and docs in a rhythmic dance,
Hoppy changes—the code’s enhanced!
🥕 Leaping through updates with a joyful prance!

Tip

🌐 Web search-backed reviews and chat
  • We have enabled web search-based reviews and chat for all users. This feature allows CodeRabbit to access the latest documentation and information on the web.
  • You can disable this feature by setting web_search: false in the knowledge_base settings.
  • Please share any feedback in the Discord discussion.
✨ Finishing Touches
  • 📝 Generate Docstrings (Beta)

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
🪧 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>, please review it.
    • 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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @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.
    • @coderabbitai help me debug CodeRabbit configuration file.

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 using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration 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.

@vincentwschau vincentwschau changed the title Only return recent best effort canceled orders. [BUG2-156] Only return recent best effort canceled orders. Feb 5, 2025
Copy link

linear bot commented Feb 5, 2025

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🔭 Outside diff range comments (1)
indexer/packages/postgres/src/types/query-types.ts (1)

75-75: Define a more specific type for initialMessage.

Using Object as a type is too broad and provides little type safety. Since the value is ['a', 'b'], consider using a more specific type.

Apply this diff to improve type safety:

-const initialMessage: Object = ['a', 'b'];
+const initialMessage: string[] = ['a', 'b'];
🧹 Nitpick comments (3)
indexer/services/socks/src/lib/subscription.ts (1)

557-559: Consider making the block range configurable.

The hardcoded value of 20 blocks in the URL query parameter could be moved to a configuration variable for better maintainability and flexibility.

+const RECENT_BLOCKS_RANGE = 20;  // Move to config
 const blockHeight: string = await blockHeightRefresher.getLatestBlockHeight();
 const numBlockHeight: number = parseInt(blockHeight, 10);
 
 // Use the config variable
-url: `${COMLINK_URL}/v4/orders?address=${address}&subaccountNumber=${subaccountNumber}&status=BEST_EFFORT_CANCELED&goodTilBlockAfter=${numBlockHeight - 20}`,
+url: `${COMLINK_URL}/v4/orders?address=${address}&subaccountNumber=${subaccountNumber}&status=BEST_EFFORT_CANCELED&goodTilBlockAfter=${numBlockHeight - RECENT_BLOCKS_RANGE}`,

Also applies to: 588-596

indexer/services/comlink/public/api-documentation.md (2)

2000-2008: New Query Parameters for ListOrders Endpoint

The addition of the parameters goodTilBlockAfter and goodTilBlockTimeAfter (along with their “BeforeOrAt” counterparts) appears to be implemented correctly. However, the current description column lists "none" for these parameters. It would improve usability to add brief descriptive texts that explain these parameters (e.g. “Filter orders with a goodTilBlock greater than the provided block height” and “Filter orders with a goodTilBlockTime after the provided ISO timestamp”). This will help client developers understand the filtering behavior—especially in light of the PR’s goal to only return recent best effort canceled orders.


2190-2208: New Query Parameters for ListOrdersForParentSubaccount Endpoint

Similarly, for the GET /orders/parentSubaccountNumber endpoint, the new query parameters goodTilBlockAfter and goodTilBlockTimeAfter have been added. Please consider updating their description fields to clarify their function. Consistency is key, so the documentation for this endpoint should mirror the explanations provided for the standard ListOrders endpoint. This consistency will reduce client confusion and ensure that filtering for recent best effort canceled orders is clearly communicated.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ffaa0d1 and 5e0f39a.

📒 Files selected for processing (10)
  • indexer/packages/postgres/__tests__/stores/order-table.test.ts (1 hunks)
  • indexer/packages/postgres/src/stores/order-table.ts (3 hunks)
  • indexer/packages/postgres/src/types/query-types.ts (2 hunks)
  • indexer/services/comlink/__tests__/controllers/api/v4/orders-controller.test.ts (5 hunks)
  • indexer/services/comlink/public/api-documentation.md (2 hunks)
  • indexer/services/comlink/public/swagger.json (4 hunks)
  • indexer/services/comlink/src/controllers/api/v4/orders-controller.ts (15 hunks)
  • indexer/services/comlink/src/types.ts (2 hunks)
  • indexer/services/socks/__tests__/lib/subscriptions.test.ts (1 hunks)
  • indexer/services/socks/src/lib/subscription.ts (6 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
indexer/services/socks/__tests__/lib/subscriptions.test.ts

[error] 75-75: Don't use 'Object' as a type.

Prefer explicitly define the object shape. This type means "any non-nullable value", which is slightly better than 'unknown', but it's still a broad type.

(lint/complexity/noBannedTypes)

⏰ Context from checks skipped due to timeout of 90000ms (13)
  • GitHub Check: call-build-ecs-service-vulcan / (vulcan) Check docker image build
  • GitHub Check: call-build-ecs-service-socks / (socks) Check docker image build
  • GitHub Check: call-build-ecs-service-roundtable / (roundtable) Check docker image build
  • GitHub Check: call-build-ecs-service-ender / (ender) Check docker image build
  • GitHub Check: call-build-ecs-service-comlink / (comlink) Check docker image build
  • GitHub Check: check-build-bazooka
  • GitHub Check: test / run_command
  • GitHub Check: check-build-auxo
  • GitHub Check: lint
  • GitHub Check: run_command
  • GitHub Check: Analyze (javascript-typescript)
  • GitHub Check: Analyze (go)
  • GitHub Check: Summary
🔇 Additional comments (10)
indexer/packages/postgres/src/stores/order-table.ts (1)

171-179: LGTM! The filtering logic is well-implemented.

The implementation of goodTilBlockAfter and goodTilBlockTimeAfter filters follows the established patterns, correctly handles null values, and uses appropriate comparison operators.

Also applies to: 191-199

indexer/packages/postgres/src/types/query-types.ts (1)

61-61: LGTM! The enum values are well-defined.

The new enum values follow the established naming convention and pattern.

Also applies to: 63-63

indexer/services/socks/__tests__/lib/subscriptions.test.ts (1)

61-62: LGTM! The URL patterns are correctly updated.

The URL patterns are appropriately split to handle BEST_EFFORT_CANCELED orders separately with the new goodTilBlockAfter parameter.

Also applies to: 70-71

indexer/packages/postgres/__tests__/stores/order-table.test.ts (1)

257-278: LGTM! The test cases provide good coverage.

The new test cases thoroughly verify the filtering logic for goodTilBlockAfter and goodTilBlockTimeAfter, including proper handling of null values.

indexer/services/comlink/src/types.ts (1)

532-534: LGTM! The new filter parameters are properly typed.

The addition of optional properties goodTilBlockAfter and goodTilBlockTimeAfter to both interfaces is consistent and well-structured.

Also applies to: 544-546

indexer/services/comlink/src/controllers/api/v4/orders-controller.ts (1)

87-89: LGTM! The new filter parameters are properly integrated.

The changes consistently:

  1. Update function signatures with new parameters
  2. Add parameters to query config
  3. Include proper validation schema for new parameters

Also applies to: 106-108, 131-133, 216-218, 232-234, 249-251, 269-271, 368-374, 380-384

indexer/services/socks/src/lib/subscription.ts (1)

599-604: LGTM! The order merging logic is correct.

The parsing and concatenation of orders from multiple responses is implemented correctly.

indexer/services/comlink/__tests__/controllers/api/v4/orders-controller.test.ts (1)

448-511: LGTM! The test coverage is comprehensive.

The new test cases thoroughly validate:

  1. Block-based filtering with goodTilBlockAfter
  2. Time-based filtering with goodTilBlockTimeAfter
  3. Edge cases and proper error handling
indexer/services/comlink/public/swagger.json (2)

2753-2777: New Query Parameters for Orders Filtering

The new parameters goodTilBlockAfter (a number with double format) and goodTilBlockTimeAfter (an ISO timestamp via the IsoString schema) have been correctly added in the /orders endpoint. They are defined as optional, which is appropriate for filtering best effort canceled orders based on block height and time. This change aligns with the PR objective of returning only recent best effort canceled orders. Please ensure that the backend query logic is updated correspondingly to use these filters.


2879-2903: New Query Parameters for Parent Subaccount Orders

The additions of goodTilBlockAfter and goodTilBlockTimeAfter in the /orders/parentSubaccountNumber endpoint mirror those in the /orders endpoint. The definitions correctly use the double format for block height and refer to the IsoString schema for the timestamp. This consistency is beneficial for API consumers and supports the intended filtering behavior. Verify that the corresponding service logic and database queries properly incorporate these new parameters.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
indexer/services/comlink/__tests__/controllers/api/v4/orders-controller.test.ts (1)

203-1052: Add test case for 20-block limit on best effort canceled orders.

While the test suite comprehensively covers the new filtering parameters, consider adding a specific test case that validates the requirement to return only best effort canceled orders from the last 20 blocks. This would ensure the core objective of the PR is thoroughly tested.

Example test case structure:

it('Successfully returns only best effort canceled orders from last 20 blocks', async () => {
  // Setup orders at different block heights
  const currentBlock = 1000;
  const orders = [
    // Order within 20 blocks
    { ...testConstants.defaultOrder, goodTilBlock: currentBlock - 10 },
    // Order outside 20 blocks
    { ...testConstants.defaultOrder, goodTilBlock: currentBlock - 30 },
  ];
  
  await Promise.all(orders.map(order => OrderTable.create(order)));

  const response = await sendRequest({
    type: RequestMethod.GET,
    path: `/v4/orders?${getQueryString({
      ...defaultQueryParams,
      status: APIOrderStatusEnum.BEST_EFFORT_CANCELED,
      goodTilBlockAfter: currentBlock - 20,
    })}`,
  });

  expect(response.body).toHaveLength(1);
  expect(response.body[0].goodTilBlock).toBe(currentBlock - 10);
});
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b55bf0b and f230b97.

📒 Files selected for processing (1)
  • indexer/services/comlink/__tests__/controllers/api/v4/orders-controller.test.ts (4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (13)
  • GitHub Check: call-build-ecs-service-vulcan / (vulcan) Check docker image build
  • GitHub Check: call-build-ecs-service-socks / (socks) Check docker image build
  • GitHub Check: call-build-ecs-service-roundtable / (roundtable) Check docker image build
  • GitHub Check: call-build-ecs-service-comlink / (comlink) Check docker image build
  • GitHub Check: test / run_command
  • GitHub Check: call-build-ecs-service-ender / (ender) Check docker image build
  • GitHub Check: check-build-bazooka
  • GitHub Check: check-build-auxo
  • GitHub Check: lint
  • GitHub Check: run_command
  • GitHub Check: Analyze (javascript-typescript)
  • GitHub Check: Analyze (go)
  • GitHub Check: Summary
🔇 Additional comments (3)
indexer/services/comlink/__tests__/controllers/api/v4/orders-controller.test.ts (3)

412-425: LGTM! Parameter renaming is consistent and well-tested.

The test cases for goodTilBlockBeforeOrAt parameter are comprehensive and cover both regular and isolated market scenarios.

Also applies to: 427-445


447-480: LGTM! New test cases for goodTilBlockAfter are thorough.

The test cases effectively validate the new goodTilBlockAfter parameter for both regular and isolated market scenarios, ensuring proper filtering of orders based on block height.


497-508: LGTM! Test cases for goodTilBlockTimeAfter are well-implemented.

The test cases validate the new goodTilBlockTimeAfter parameter using ISO timestamp format, ensuring proper filtering of orders based on block time.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 64b29a2 and 5ec2842.

📒 Files selected for processing (1)
  • indexer/services/socks/__tests__/lib/message-forwarder.test.ts (1 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
indexer/services/socks/__tests__/lib/message-forwarder.test.ts

[error] 177-177: Don't use 'Object' as a type.

Prefer explicitly define the object shape. This type means "any non-nullable value", which is slightly better than 'unknown', but it's still a broad type.

(lint/complexity/noBannedTypes)


[error] 178-178: Don't use 'Object' as a type.

Prefer explicitly define the object shape. This type means "any non-nullable value", which is slightly better than 'unknown', but it's still a broad type.

(lint/complexity/noBannedTypes)

⏰ Context from checks skipped due to timeout of 90000ms (13)
  • GitHub Check: call-build-ecs-service-vulcan / (vulcan) Check docker image build
  • GitHub Check: call-build-ecs-service-socks / (socks) Check docker image build
  • GitHub Check: call-build-ecs-service-roundtable / (roundtable) Check docker image build
  • GitHub Check: call-build-ecs-service-ender / (ender) Check docker image build
  • GitHub Check: call-build-ecs-service-comlink / (comlink) Check docker image build
  • GitHub Check: check-build-bazooka
  • GitHub Check: test / run_command
  • GitHub Check: check-build-auxo
  • GitHub Check: lint
  • GitHub Check: run_command
  • GitHub Check: Analyze (javascript-typescript)
  • GitHub Check: Analyze (go)
  • GitHub Check: Summary
🔇 Additional comments (1)
indexer/services/socks/__tests__/lib/message-forwarder.test.ts (1)

177-181: Verify test coverage for the new order fetching behavior.

The test data structure has been modified from an object to an array, which suggests changes in the API response format. Let's verify that the test cases adequately cover the new order fetching behavior.

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Search for related test files and their coverage of order fetching scenarios
fd "test.*\.(ts|js)$" | xargs rg -l "orders.*concat|orders.*filter"

# Search for order-related test assertions
rg "expect.*orders" --type ts

Length of output: 3067


Order Fetching Behavior Test Coverage Confirmed

The tests adequately assert the new behavior where orders are now represented as an array. Key findings include:

  • The test in indexer/services/socks/__tests__/lib/message-forwarder.test.ts explicitly uses array concatenation (via .concat) to construct the orders property.
  • Additional tests (e.g., in e2e tests and in indexer/packages/postgres/__tests__/stores/order-table.test.ts) validate the structure by asserting on array length and content using methods like expect(...).toHaveLength and object comparisons.
  • Overall, the modifications in the API response (object to array) are reflected in the test assertions across multiple test files, ensuring that the new order fetching behavior is properly covered.
🧰 Tools
🪛 Biome (1.9.4)

[error] 177-177: Don't use 'Object' as a type.

Prefer explicitly define the object shape. This type means "any non-nullable value", which is slightly better than 'unknown', but it's still a broad type.

(lint/complexity/noBannedTypes)


[error] 178-178: Don't use 'Object' as a type.

Prefer explicitly define the object shape. This type means "any non-nullable value", which is slightly better than 'unknown', but it's still a broad type.

(lint/complexity/noBannedTypes)

Comment on lines +177 to 181
const mockAxiosResponse: Object[] = ['a', 'b'];
const subaccountInitialMessage: Object = {
...mockAxiosResponse,
orders: mockAxiosResponse,
orders: mockAxiosResponse.concat(mockAxiosResponse),
blockHeight: '2',
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Replace Object type with a more specific type definition.

The current use of Object type is too broad and can hide potential type-related bugs. Consider using a more specific type that matches the actual data structure.

-const mockAxiosResponse: Object[] = ['a', 'b'];
-const subaccountInitialMessage: Object = {
+type OrderData = string;  // Update this type to match the actual order data structure
+const mockAxiosResponse: OrderData[] = ['a', 'b'];
+const subaccountInitialMessage: {
+  orders: OrderData[];
+  blockHeight: string;
+} = {
   ...mockAxiosResponse,
   orders: mockAxiosResponse.concat(mockAxiosResponse),
   blockHeight: '2',
};

Additionally, consider adding a comment to document the test data structure and its relationship to the actual API response format.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
const mockAxiosResponse: Object[] = ['a', 'b'];
const subaccountInitialMessage: Object = {
...mockAxiosResponse,
orders: mockAxiosResponse,
orders: mockAxiosResponse.concat(mockAxiosResponse),
blockHeight: '2',
type OrderData = string; // Update this type to match the actual order data structure
const mockAxiosResponse: OrderData[] = ['a', 'b'];
const subaccountInitialMessage: {
orders: OrderData[];
blockHeight: string;
} = {
...mockAxiosResponse,
orders: mockAxiosResponse.concat(mockAxiosResponse),
blockHeight: '2',
};
🧰 Tools
🪛 Biome (1.9.4)

[error] 177-177: Don't use 'Object' as a type.

Prefer explicitly define the object shape. This type means "any non-nullable value", which is slightly better than 'unknown', but it's still a broad type.

(lint/complexity/noBannedTypes)


[error] 178-178: Don't use 'Object' as a type.

Prefer explicitly define the object shape. This type means "any non-nullable value", which is slightly better than 'unknown', but it's still a broad type.

(lint/complexity/noBannedTypes)

@vincentwschau vincentwschau merged commit d425749 into main Feb 7, 2025
16 checks passed
@vincentwschau vincentwschau deleted the vincentc/fix-best-effort-canceled-orders branch February 7, 2025 14:41
@vincentwschau
Copy link
Contributor Author

@Mergifyio backport release/indexer/v8.x

Copy link
Contributor

mergify bot commented Feb 18, 2025

backport release/indexer/v8.x

✅ Backports have been created

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

Successfully merging this pull request may close these issues.

3 participants