Add withdraw all buttons on Order Details page#2002
Conversation
WalkthroughThis change introduces support for batch withdrawals ("Withdraw all") from multiple vaults, including backend (Rust, Tauri) and frontend (Svelte, TypeScript) implementations. New modules and components enable multicall calldata generation, UI for grouped vault withdrawals, and transaction management for multi-vault operations. Related tests, types, and error handling are updated accordingly. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI (OrderDetail/VaultsListTable)
participant WithdrawMultipleModal
participant Service (handleMultipleVaultsWithdraw / multiVaultsWithdraw)
participant Backend (Rust/Tauri)
participant Blockchain
User->>UI (OrderDetail/VaultsListTable): Click "Withdraw all"
UI->>WithdrawMultipleModal: Open modal with selected vaults
WithdrawMultipleModal->>User: Display vaults, confirm withdrawal
User->>WithdrawMultipleModal: Confirm "Withdraw All"
WithdrawMultipleModal->>Service: onSubmit (vaults, account, etc.)
Service->>Backend: Prepare multicall calldata, validate vaults
Backend->>Blockchain: Submit multicall transaction
Blockchain-->>Backend: Transaction receipt
Backend-->>Service: Success/failure
Service-->>WithdrawMultipleModal: Notify result
WithdrawMultipleModal-->>UI: Close modal, refresh data
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes detected. Suggested labels
Suggested reviewers
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
brusherru
force-pushed
the
feat-1963-withdraw-all
branch
2 times, most recently
from
1df4f63 to
191e873
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
brusherru
force-pushed
the
feat-1963-withdraw-all
branch
from
191e873 to
6e01c90
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
crates/common/src/withdraw_multiple.rs (1)
31-31: Consider making retry count configurableThe hardcoded retry count of 4 might not be suitable for all scenarios. Consider making this configurable through TransactionArgs or as a parameter.
- WriteTransaction::new(ledger_client.client, params, 4, transaction_status_changed) + let retry_count = transaction_args.retry_count.unwrap_or(4); + WriteTransaction::new(ledger_client.client, params, retry_count, transaction_status_changed)tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte (1)
38-71: Address the multicall logic duplication as noted in previous review.The
executeWalletconnectfunction duplicates multicall generation logic that exists inhandleMultipleVaultsWithdraw.ts. This creates maintenance burden and potential inconsistencies.Additionally, there's a potential issue with the orderbook assumption:
- const orderbook = vaults[0].orderbook; // Assuming all vaults belong to the same orderbook + const orderbook = vaults[0].orderbook; + // Verify all vaults belong to the same orderbook + const allSameOrderbook = vaults.every(vault => vault.orderbook === orderbook); + if (!allSameOrderbook) { + throw new Error('All vaults must belong to the same orderbook'); + }
brusherru
force-pushed
the
feat-1963-withdraw-all
branch
3 times, most recently
from
b26e9de to
27db65c
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
tauri-app/src/routes/vaults/+page.svelte (1)
24-26: Empty callback lacks data refresh logic after withdrawal.The
onWithdrawMultiplefunction passes an empty callback tohandleWithdrawMultipleModal, missing the opportunity to refresh vault data after successful withdrawal. This is inconsistent with the established pattern used in other handlers and the order detail page.Consider adding query invalidation logic similar to other handlers:
function onWithdrawMultiple(_raindexClient: RaindexClient, vaults: RaindexVault[]) { - handleWithdrawMultipleModal(vaults, () => {}); + handleWithdrawMultipleModal(vaults, () => { + // Add appropriate data refresh logic here + }); }packages/ui-components/src/lib/providers/transactions/TransactionManager.ts (1)
174-229: LGTM: Well-implemented method following established patterns.The
createMultipleVaultsWithdrawTransactionmethod correctly implements batch withdrawal transaction creation by:
- Following the same pattern as other transaction creation methods
- Properly documenting the orderbook assumption with clear comments (lines 198-200)
- Using appropriate transaction metadata (
TransactionName.WITHDRAWAL_MULTIPLE)- Creating suitable toast links (general vaults page + explorer)
- Reusing the same
awaitSubgraphConfigpattern as single vault withdrawal- Maintaining consistent error handling and return types
The orderbook assumption concern from previous reviews has been addressed with explicit documentation indicating validation should occur before calling this method.
crates/js_api/src/gui/multicall.rs (1)
40-43: LGTM: Proper WASM binding configuration.The
wasm_exportattribute is correctly configured withoutunchecked_return_type, which allows proper error handling and propagation to JavaScript. This addresses the return type inconsistency concern from previous reviews.
findolor
left a comment
findolor
left a comment
There was a problem hiding this comment.
there are two more things i've noticed
- there is an issue with tooltip on the order details page
- the withdraw button in order details are not reacting to me connecting/disconnecting my wallet. i have to refresh to get the withdraw all button.
| throw new Error('All vaults must share the same orderbook for batch withdrawal'); | ||
| } | ||
| // Get individual withdrawal calldatas | ||
| const calldatas = await Promise.all( |
There was a problem hiding this comment.
i think it makes more sense to move this loop logic for getting all of the withdraw calldatas one by one to raindex client. we can do something like:
raindexClient.getVaultWithdrawCalldatas(selectedVaults)that way we don't have to create extra logic on the UI.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
tauri-app/src/lib/services/modal.ts (1)
8-8: Use $lib alias for consistency.-import ModalMultipleVaultsWithdraw from '../components/ModalMultipleVaultsWithdraw.svelte'; +import ModalMultipleVaultsWithdraw from '$lib/components/ModalMultipleVaultsWithdraw.svelte';tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte (1)
44-77: Verify if multicall duplication was addressed.Based on past review comments, this section had duplicate multicall logic. The code has been marked as addressed, but the implementation still contains inline multicall generation logic that could potentially be extracted for reusability.
The multicall generation logic (lines 47-65) appears to duplicate patterns that could be shared across components. Consider whether this was fully addressed as indicated in the past review.
brusherru
force-pushed
the
feat-1963-withdraw-all
branch
from
53d8170 to
b9930d1
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
packages/ui-components/src/lib/utils/account.ts(1 hunks)tauri-app/src/routes/vaults/+page.svelte(3 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an `onRemove` callback approach instead of the previous `handleOrderRemoveModal` pattern for order removal functionality, as part of PR #1512.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, `VaultCalldataResult` is a wrapper type that contains both `error` and `value` properties. When using this in the `DepositOrWithdrawModal` component, only the inner `value` field is passed to the `handleTransaction` function, not the complete wrapper.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option<U256> to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
packages/ui-components/src/lib/utils/account.ts (1)
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
tauri-app/src/routes/vaults/+page.svelte (22)
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1651
File: packages/ui-components/src/lib/components/TanstackAppTable.svelte:13-13
Timestamp: 2025-04-10T16:32:51.198Z
Learning: In the TanstackAppTable.svelte component, the queryKey prop should be required (type: string) rather than optional (string | undefined) to ensure proper query invalidation.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: hardingjam
PR: #1565
File: packages/webapp/src/routes/deploy/+layout.svelte:12-16
Timestamp: 2025-04-09T09:59:04.121Z
Learning: In the Rain Orderbook application, a full page reload (window.location.reload()) is needed when changing the registry URL to ensure proper state reinitialization, rather than using SvelteKit's soft navigation methods.
Learnt from: findolor
PR: #1917
File: tauri-app/src/lib/stores/order.ts:10-15
Timestamp: 2025-06-11T11:27:14.391Z
Learning: In this codebase, Svelte writable/derived stores (e.g., subgraph in tauri-app/src/lib/stores/settings.ts) expose a custom asynchronous .load() helper that retrieves the current value, so calls like await subgraph.load() are valid.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use enabled: true rather than Object.keys($activeSubgraphs).length > 0 because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (17)
- GitHub Check: test
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-test)
- GitHub Check: Deploy-Docs-Preview
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-artifacts, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: git-clean
- GitHub Check: test
- GitHub Check: test
- GitHub Check: Deploy-Preview
🔇 Additional comments (6)
tauri-app/src/routes/vaults/+page.svelte (5)
2-7: LGTM! Imports are correctly expanded for batch withdrawal functionality.The new imports for
invalidateTanstackQueriesandQKEY_VAULTSare necessary for implementing proper cache invalidation after multiple vault withdrawals.
21-25: LGTM! Modal service imports correctly expanded.The addition of
handleWithdrawMultipleModalfollows the established pattern for modal service imports.
27-28: LGTM! Type and query client imports are correct.Good use of the
$lib/queries/syntax as requested. TheRaindexVaulttype import is necessary for the new function parameter.
30-45: Excellent implementation that addresses previous feedback!The function correctly implements:
- Promise-based async pattern for modal handling
- Proper cache invalidation using
invalidateTanstackQuerieswithQKEY_VAULTS- Both success and cancel callback handling
- Return values indicating operation outcome
This addresses the previous review comment about adding data refresh logic and follows established patterns from other withdrawal functions in the codebase.
61-61: LGTM! Prop correctly passed to enable batch withdrawal functionality.The
onWithdrawMultiplefunction is properly passed as a prop toVaultsListTable, following the established pattern for callback functions.packages/ui-components/src/lib/utils/account.ts (1)
1-1: LGTM! Import statement is correct.The necessary viem utilities for address validation and comparison are properly imported.
brusherru
force-pushed
the
feat-1963-withdraw-all
branch
from
b9930d1 to
050c96b
Compare
| pub struct MulticallCalldataResult(#[tsify(type = "string")] Bytes); | ||
| impl_wasm_traits!(MulticallCalldataResult); | ||
|
|
||
| /// Generates multicall calldata from an array of individual calldatas. |
There was a problem hiding this comment.
i think it would make sense to specify this is for orderbook only. we are not generating multicall calldata for any other purpose but doing it for the orderbook contract. doing this would remove confusion
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (1)
40-42: Consider using vaultId instead of subgraph id for display consistency.The vault display uses
vault.idas the key, but displaystoHex(vault.vaultId). For better user experience and consistency with past feedback, consider using the vaultId as the key as well since that's what users see in the UI.-{#each args.vaults as vault (vault.id)} +{#each args.vaults as vault (vault.vaultId)}crates/js_api/src/multicall.rs (1)
11-16: Clarify that this is specifically for OrderBook multicall functionality.As noted in past feedback, it would be helpful to specify in the documentation that this generates multicall calldata specifically for the OrderBook contract to remove confusion about its purpose.
-/// Generates multicall calldata to Orderbook smart contract +/// Generates multicall calldata for the OrderBook smart contract /// from an array of individual calldatas. /// /// Takes an array of hex-encoded calldata strings and combines them into a single -/// multicall transaction that executes all of them atomically. +/// multicall transaction that executes all of them atomically on the OrderBook.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
crates/js_api/src/multicall.rs(1 hunks)packages/webapp/src/lib/components/WithdrawMultipleModal.svelte(1 hunks)tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an `onRemove` callback approach instead of the previous `handleOrderRemoveModal` pattern for order removal functionality, as part of PR #1512.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, `VaultCalldataResult` is a wrapper type that contains both `error` and `value` properties. When using this in the `DepositOrWithdrawModal` component, only the inner `value` field is passed to the `handleTransaction` function, not the complete wrapper.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option<U256> to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (14)
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte (18)
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: hardingjam
PR: #1896
File: tauri-app/src/lib/services/executeWalletConnectOrder.ts:41-45
Timestamp: 2025-05-27T12:01:51.647Z
Learning: In the tauri-app codebase, the formatEthersTransactionErrorFn function already handles error formatting appropriately for toast messages in executeWalletConnectOrder, so additional granular error handling based on error types is not needed.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:33-33
Timestamp: 2025-05-20T12:01:28.391Z
Learning: In the rain.orderbook project, transaction success handling in modal components is managed by the TransactionModal component and listeners that handle adding toasts, rather than directly invoking callbacks. This is part of the architecture being refactored as transactions are moved to the TransactionManager.
Learnt from: findolor
PR: #1469
File: packages/ui-components/src/tests/CodeMirrorDotrain.test.ts:75-98
Timestamp: 2025-03-31T10:16:53.544Z
Learning: In the rainlanguage/rain.orderbook project, direct manipulation of Svelte's internal state (component.$$.ctx) in tests is an acceptable approach for testing component behavior, as demonstrated in the CodeMirrorDotrain tests.
crates/js_api/src/multicall.rs (19)
Learnt from: findolor
PR: #1903
File: crates/cli/src/commands/order/calldata.rs:47-57
Timestamp: 2025-06-17T16:46:19.035Z
Learning: In the CLI command crates/cli/src/commands/order/calldata.rs, the user prefers to let lower-level errors from try_into_call() bubble up when the RPCs list is empty, rather than adding early validation checks with custom error messages.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Learnt from: findolor
PR: #1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The wasm_bindgen_utils crate in the Rain Orderbook project handles conditional compilation for JsValue and JsError internally, allowing impl From<Error> for JsValue to work on non-WASM targets without explicit cfg guards.
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: findolor
PR: #1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.511Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: findolor
PR: #1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: 0xgleb
PR: #1846
File: crates/quote/src/quote.rs:309-317
Timestamp: 2025-05-20T15:34:06.751Z
Learning: In Rust, when importing from the alloy crate, use alloy::hex; imports the hex macro, not a module, so it can't be consolidated with imports like use alloy::hex::ToHex; using the grouped import syntax.
Learnt from: thedavidmeister
PR: #1926
File: src/concrete/ob/OrderBook.sol:97-99
Timestamp: 2025-06-16T10:46:39.129Z
Learning: In OrderBook.sol, thedavidmeister prefers error definitions that are self-descriptive when the error condition is specific enough. For ClearZeroAmount, since it only fires when both output amounts are zero, the error name itself provides sufficient context without needing to include the zero values as parameters.
Learnt from: findolor
PR: #1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: #1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: findolor
PR: #1882
File: packages/ui-components/src/lib/types/modal.ts:31-31
Timestamp: 2025-06-07T09:15:27.885Z
Learning: In the rain.orderbook project, toAddress and orderbookAddress are distinct variables serving different purposes: toAddress is used in transaction confirmation modals (particularly for deposits) to represent the transaction recipient, while orderbookAddress is used elsewhere for orderbook-specific logic outside of deposit-related flows.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:101-105
Timestamp: 2025-04-30T10:32:53.866Z
Learning: In the rain.orderbook project, the get_remove_order_calldata function takes SgOrder by value rather than by reference, as per maintainer preference.
Learnt from: findolor
PR: #1938
File: crates/settings/src/yaml/orderbook.rs:185-199
Timestamp: 2025-06-18T19:24:40.518Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers not to refactor get_orderbook_by_network_key to handle multiple orderbooks per network key since their current architecture maintains a one-to-one mapping between orderbooks and networks. They would consider the refactoring if the system evolves to support multiple orderbooks per network in the future.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: #1907
File: packages/orderbook/test/common/test.test.ts:75-77
Timestamp: 2025-06-04T10:21:01.388Z
Learning: The DotrainOrder.create API in packages/orderbook/test/common/test.test.ts is internal and not used directly in consumer applications, so API changes here don't require external breaking change documentation.
Learnt from: findolor
PR: #1646
File: crates/settings/src/scenario.rs:1-1
Timestamp: 2025-04-10T11:08:33.383Z
Learning: Wildcard imports (using *) are acceptable in the rain.orderbook codebase, as per the author's preference.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using #[cfg(target_family = "wasm")] and #[cfg(not(target_family = "wasm"))], and don't require additional wasm_bindgen_test_configure!(run_in_browser) directives.
Learnt from: findolor
PR: #1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (17)
- GitHub Check: git-clean
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: Deploy-Preview
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-test)
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-artifacts, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: Deploy-Docs-Preview
- GitHub Check: test
🔇 Additional comments (9)
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (2)
1-26: Component setup looks good with proper modal pattern implementation.The component follows established modal patterns from the codebase with proper prop definitions, imports, and event handling structure. The conditional wallet connection check aligns with similar components in the project.
44-46: LGTM! Using formattedBalance field as recommended.Good implementation using the
formattedBalancefield from the vault object instead of manually formatting withformatUnits, which aligns with the established pattern and past feedback.crates/js_api/src/multicall.rs (3)
46-85: Robust implementation with comprehensive input validation.The function properly validates input calldata with good error messages including indices. The hex parsing, length validation, and ABI encoding logic is correct. Error handling provides helpful context for debugging.
90-117: Well-structured error handling with proper WASM integration.The error enum and conversion implementations follow established patterns in the codebase. The
to_readable_msgmethod provides user-friendly error messages, and the WASM bindings are properly implemented.
122-226: Excellent test coverage including edge cases and realistic examples.The test suite covers all important scenarios:
- Success cases with multiple and single calldata
- Error cases: empty input, invalid hex, odd length, empty strings
- Realistic examples with actual ERC20 calldata
- Error message formatting
This provides confidence in the implementation's robustness.
tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte (4)
32-42: Clean Ledger execution implementation.The Ledger execution path properly handles the async operation with appropriate error reporting to Sentry and state management. The pattern follows established conventions in the codebase.
44-77: WalletConnect execution properly handles multicall generation.The implementation correctly:
- Generates individual calldata for each vault
- Handles calldata errors with readable messages
- Uses the new
generateMulticallCalldatafunction- Validates the generated calldata
- Executes via ethersExecute with proper error handling
The multicall logic appears to have been properly abstracted as noted in past feedback.
90-101: Vault display matches webapp component pattern.The vault display UI is consistent with the webapp version, using
toHex(vault.vaultId)for ID display andvault.formattedBalancefor balance. Good consistency across platforms.
119-128: ModalExecute integration follows established patterns.The integration with
ModalExecuteproperly passes through the execution functions and state management. The chainId is correctly taken from the first vault, consistent with the orderbook assumption.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (1)
23-25: Avoid directly mutating theopenpropDirectly setting
open = falseviolates Svelte's one-way data flow principles.Consider using event dispatching or binding the modal's open state properly:
+ import { createEventDispatcher } from 'svelte'; + const dispatch = createEventDispatcher(); + function handleClose() { - open = false; + dispatch('close'); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte(1 hunks)tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte(1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an `onRemove` callback approach instead of the previous `handleOrderRemoveModal` pattern for order removal functionality, as part of PR #1512.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, `VaultCalldataResult` is a wrapper type that contains both `error` and `value` properties. When using this in the `DepositOrWithdrawModal` component, only the inner `value` field is passed to the `handleTransaction` function, not the complete wrapper.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option<U256> to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (16)
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1494
File: packages/ui-components/src/tests/WalletProvider.test.ts:18-28
Timestamp: 2025-03-24T12:27:07.862Z
Learning: In the WalletProvider tests, verifying that setAccountContext is called with the correct store is sufficient. Additional testing of Svelte's store implementation (like subscribing to verify the store value) is unnecessary as it would just be testing the framework itself.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte (22)
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: hardingjam
PR: #1896
File: tauri-app/src/lib/services/executeWalletConnectOrder.ts:41-45
Timestamp: 2025-05-27T12:01:51.647Z
Learning: In the tauri-app codebase, the formatEthersTransactionErrorFn function already handles error formatting appropriately for toast messages in executeWalletConnectOrder, so additional granular error handling based on error types is not needed.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:33-33
Timestamp: 2025-05-20T12:01:28.391Z
Learning: In the rain.orderbook project, transaction success handling in modal components is managed by the TransactionModal component and listeners that handle adding toasts, rather than directly invoking callbacks. This is part of the architecture being refactored as transactions are moved to the TransactionManager.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: findolor
PR: #1469
File: packages/ui-components/src/tests/CodeMirrorDotrain.test.ts:75-98
Timestamp: 2025-03-31T10:16:53.544Z
Learning: In the rainlanguage/rain.orderbook project, direct manipulation of Svelte's internal state (component.$$.ctx) in tests is an acceptable approach for testing component behavior, as demonstrated in the CodeMirrorDotrain tests.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (17)
- GitHub Check: git-clean
- GitHub Check: test
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: test
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-artifacts, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-static)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: Deploy-Preview
- GitHub Check: Deploy-Docs-Preview
🔇 Additional comments (1)
tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte (1)
74-77: Use a shared confirmation constantReplace the hard-coded
1intx.wait(1)with the sharedTRANSACTION_CONFIRMATIONSvalue to keep the front-end in sync with the back-end. Currently, we didn’t find a JS/TS export for this constant—please verify that you’ve exposed or defined it for use in the UI.
- File:
tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte
Lines 74–77:const tx = await ethersExecute(calldataBytes, orderbook); toasts.success('Transaction sent successfully!');await tx.wait(1);
await tx.wait(TRANSACTION_CONFIRMATIONS); onWithdraw();
- Ensure
TRANSACTION_CONFIRMATIONSis imported or otherwise made available in the front-end (matching the value fromcrates/common/src/transaction.rs).
| function reset() { | ||
| open = false; | ||
| if (!isSubmitting) { | ||
| selectWallet = false; | ||
| } | ||
| } |
There was a problem hiding this comment.
Avoid directly mutating the open prop
Directly setting open = false violates Svelte's one-way data flow. Props should be treated as read-only.
Consider using a local state variable or dispatching an event to the parent:
+ import { createEventDispatcher } from 'svelte';
+ const dispatch = createEventDispatcher();
+
function reset() {
- open = false;
+ dispatch('close');
if (!isSubmitting) {
selectWallet = false;
}
}📝 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.
| function reset() { | |
| open = false; | |
| if (!isSubmitting) { | |
| selectWallet = false; | |
| } | |
| } | |
| import { createEventDispatcher } from 'svelte'; | |
| const dispatch = createEventDispatcher(); | |
| function reset() { | |
| - open = false; | |
| + dispatch('close'); | |
| if (!isSubmitting) { | |
| selectWallet = false; | |
| } | |
| } |
🤖 Prompt for AI Agents
In tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte around lines
20 to 25, the code directly mutates the `open` prop by setting `open = false`,
which breaks Svelte's one-way data flow. To fix this, avoid directly assigning
to `open`; instead, create a local state variable to control the modal's open
state or dispatch a custom event to notify the parent component to update the
`open` prop accordingly.
There was a problem hiding this comment.
I used the same approach that is used in other Modals.
Meanwhile dispatching event actually would not close the modal, so we'll need to handle that event somewhere else.
I propose to keep it as is and later probably refactor all modals at once.
There was a problem hiding this comment.
@brusherru Thank you for the clarification! You make excellent points about consistency across the codebase and the practical challenges with the event dispatching approach. Maintaining consistency with existing modal patterns is indeed more important than making isolated changes, and your plan to refactor all modals together makes much more sense from an architectural perspective.
I appreciate you explaining the existing pattern - it's better to have a consistent approach across all modals rather than introducing inconsistency with a single component change.
🐰💭
✏️ Learnings added
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#2002
File: tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte:20-25
Timestamp: 2025-07-24T08:16:47.349Z
Learning: In the Rain OrderBook Tauri app, modal components directly mutate the `open` prop (setting `open = false`) as a consistent pattern across the codebase. This approach is maintained for consistency even though it violates typical Svelte one-way data flow, with plans to refactor all modals together in the future rather than making isolated changes.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, `VaultCalldataResult` is a wrapper type that contains both `error` and `value` properties. When using this in the `DepositOrWithdrawModal` component, only the inner `value` field is passed to the `handleTransaction` function, not the complete wrapper.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:33-33
Timestamp: 2025-05-20T12:01:28.391Z
Learning: In the rain.orderbook project, transaction success handling in modal components is managed by the TransactionModal component and listeners that handle adding toasts, rather than directly invoking callbacks. This is part of the architecture being refactored as transactions are moved to the TransactionManager.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1469
File: packages/ui-components/src/__tests__/CodeMirrorDotrain.test.ts:75-98
Timestamp: 2025-03-31T10:16:53.544Z
Learning: In the rainlanguage/rain.orderbook project, direct manipulation of Svelte's internal state (component.$$.ctx) in tests is an acceptable approach for testing component behavior, as demonstrated in the CodeMirrorDotrain tests.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: packages/ui-components/src/lib/components/detail/TanstackOrderQuote.svelte:24-31
Timestamp: 2025-06-17T17:48:58.544Z
Learning: The project maintainer prefers not to use readonly modifiers on component props like rpcUrls: string[] even when they're not mutated, indicating a preference for simpler typing over stricter immutability enforcement in Svelte components.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an `onRemove` callback approach instead of the previous `handleOrderRemoveModal` pattern for order removal functionality, as part of PR #1512.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-03-31T13:58:47.329Z
Learning: In Svelte components, using `on:eventname` without a handler function implements event forwarding, allowing events to bubble up to parent components where they can be handled. This is a common and correct pattern in Svelte applications.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:35-37
Timestamp: 2025-06-17T16:25:44.685Z
Learning: In the tauri-app Svelte application, users must navigate to a settings page to modify settings and then return to other pages. This navigation pattern causes page components to be recreated, which naturally refreshes component state derived from settings without requiring reactive statements ($:). Therefore, reactive statements for settings-derived values are unnecessary when the UX flow involves page navigation.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
…allet connected/disconnected
brusherru
force-pushed
the
feat-1963-withdraw-all
branch
from
3ca9c70 to
c017ca0
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (14)
crates/common/src/raindex_client/mod.rs (1)
37-37: Consider re-exportingVaultsListfor a flatter public APIDown-stream crates / WASM consumers will now need to write
raindex_client::vaults_list::VaultsList, whereas all other helpers are already exposed at the crate root (e.g.vaults::*).
Staying consistent keeps the TS/WASM surface intuitive.pub mod vaults_list; +// Re-export for convenience and parity with `vaults::*` +pub use vaults_list::VaultsList;crates/js_api/src/gui/mod.rs (1)
654-655: Consider the location of this error variant.The new
InvalidCalldataerror variant aligns with the multicall functionality being added. However, there's a previous comment suggesting that when logic moves outside the gui directory, the corresponding errors should also be removed from this file.packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (2)
41-42: LGTM! Vault ID display uses appropriate hex formatting.Using
toHex(vault.vaultId)correctly converts the bigint vault ID to hexadecimal format for display, which aligns with the UI patterns and addresses previous feedback about vault ID consistency.
44-47: Good use of formatted balance field.Using
vault.formattedBalanceinstead of manual formatting withformatUnitsis the correct approach and addresses previous feedback about utilizing the pre-formatted field available on the vault object.packages/ui-components/src/lib/providers/transactions/TransactionManager.ts (1)
198-200: The orderbook assumption is now properly documented.The comment clearly explains that all vaults must share the same orderbook and that validation should occur before calling this method. This addresses the previous concern about making the assumption explicit.
packages/ui-components/src/lib/components/detail/OrderDetail.svelte (1)
176-176: Good replacement of address comparison method.Using
isAddressEqinstead of the previousmatchesAccountprovides more reliable Ethereum address equality checking. This change is consistent throughout the component.Also applies to: 251-251
crates/common/src/raindex_client/orders.rs (2)
164-167: Consider renaminginputs_outputs_listtoinput_output_vaults_listfor clarityThe current name could be misinterpreted as returning all inputs and outputs, when it actually returns only vaults that serve as both input and output. A name like
input_output_vaults_listordual_purpose_vaults_listwould be more descriptive.
234-236: Consider renaminginputs_outputs_listtoinput_output_vaults_listfor claritySame naming concern as the wasm version - the method name could be clearer about returning only dual-purpose vaults.
crates/js_api/src/multicall.rs (3)
11-41: Update documentation to clarify this is Orderbook-specificThe documentation should specify that this generates multicall calldata specifically for the Orderbook smart contract, as suggested in past review comments. This would remove confusion about the scope of this functionality.
-/// Generates multicall calldata to Orderbook smart contract +/// Generates multicall calldata for the Orderbook smart contract /// from an array of individual calldatas. /// /// Takes an array of hex-encoded calldata strings and combines them into a single -/// multicall transaction that executes all of them atomically. +/// multicall transaction that executes all of them atomically on the Orderbook contract.
48-48: Consider using a more specific type for hex stringsAs suggested in past review comments, consider using a hex-specific type (like viem's Hex type) instead of generic String to provide better type safety at the API boundary.
59-71: Consider simplifying hex validationThe manual validation for empty strings and odd-length hex might be redundant since
Bytes::from_hexlikely performs these checks. Consider removing the redundant validation or documenting why it's necessary for better error messages.You could verify if
Bytes::from_hexalready handles these cases:#!/bin/bash # Check how Bytes::from_hex handles edge cases in the alloy crate rg -A 10 "from_hex.*impl" --type rustcrates/common/src/raindex_client/vaults_list.rs (3)
33-37: Ensure robust zero-balance detection in WASMThe current check
vault.formatted_balance() != "0"might miss edge cases like "0.0", "0.00", or values with whitespace. Consider parsing the string to a numeric type or ensuringformatted_balance()always returns a consistent format.
46-47: Pre-allocate vector capacity for better performanceSince you know the number of vaults to withdraw from, pre-allocate the vector capacity to avoid reallocations.
- let mut calldatas: Vec<Bytes> = Vec::new(); let vaults_to_withdraw: Vec<&RaindexVault> = self.get_withdrawable_vaults(); + let mut calldatas: Vec<Bytes> = Vec::with_capacity(vaults_to_withdraw.len());
95-113: Consider documenting the difference betweennewandfromconstructorsBoth
new_wasmandfrom_wasmhave identical implementations. While this provides flexibility for JavaScript users, consider adding a comment explaining the semantic difference or intended usage patterns between these two methods.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (27)
crates/common/src/lib.rs(1 hunks)crates/common/src/raindex_client/mod.rs(1 hunks)crates/common/src/raindex_client/orders.rs(3 hunks)crates/common/src/raindex_client/vaults_list.rs(1 hunks)crates/common/src/transaction.rs(1 hunks)crates/common/src/withdraw.rs(1 hunks)crates/common/src/withdraw_multiple.rs(1 hunks)crates/js_api/src/gui/mod.rs(2 hunks)crates/js_api/src/lib.rs(1 hunks)crates/js_api/src/multicall.rs(1 hunks)packages/ui-components/src/__tests__/OrderDetail.test.ts(9 hunks)packages/ui-components/src/lib/components/detail/OrderDetail.svelte(6 hunks)packages/ui-components/src/lib/components/tables/VaultsListTable.svelte(6 hunks)packages/ui-components/src/lib/providers/transactions/TransactionManager.ts(1 hunks)packages/ui-components/src/lib/types/transaction.ts(1 hunks)packages/ui-components/src/lib/types/vaults.ts(1 hunks)packages/ui-components/src/lib/utils/account.ts(1 hunks)packages/ui-components/tsconfig.json(1 hunks)packages/webapp/src/__tests__/handleVaultDeposit.test.ts(0 hunks)packages/webapp/src/__tests__/handleVaultWithdraw.test.ts(0 hunks)packages/webapp/src/lib/components/WithdrawMultipleModal.svelte(1 hunks)packages/webapp/src/lib/services/handleMultipleVaultsWithdraw.ts(1 hunks)packages/webapp/src/lib/services/handleVaultDeposit.ts(0 hunks)packages/webapp/src/lib/services/handleVaultWithdraw.ts(0 hunks)packages/webapp/src/lib/services/modal.ts(2 hunks)packages/webapp/src/routes/orders/[chainId]-[orderbook]-[orderHash]/+page.svelte(3 hunks)packages/webapp/src/routes/vaults/+page.svelte(3 hunks)
💤 Files with no reviewable changes (4)
- packages/webapp/src/tests/handleVaultWithdraw.test.ts
- packages/webapp/src/lib/services/handleVaultWithdraw.ts
- packages/webapp/src/tests/handleVaultDeposit.test.ts
- packages/webapp/src/lib/services/handleVaultDeposit.ts
🧰 Additional context used
🧠 Learnings (24)
📓 Common learnings
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any additional text or formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:26:31.566Z
Learning: For PR #1884 and future PRs in rainlanguage/rain.orderbook repository, provide PR size reports in a separate comment with ONLY the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number", without any additional text or explanation. Reports should exclude irrelevant files such as lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:25:47.873Z
Learning: After each new commit review for rainlanguage/rain.orderbook repository, generate a PR size report in a separate comment with the format: "TOTAL=number ADDITIONS=number DELETIONS=number". This report should exclude irrelevant files such as lock files (e.g., package-lock.json, cargo.lock).
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:42.275Z
Learning: For PR #1884, after each commit review, I should provide a new comment with a PR size report in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding irrelevant files such as lock files (package-lock.json, cargo.lock, etc.).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, `VaultCalldataResult` is a wrapper type that contains both `error` and `value` properties. When using this in the `DepositOrWithdrawModal` component, only the inner `value` field is passed to the `handleTransaction` function, not the complete wrapper.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option<U256> to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
crates/common/src/lib.rs (10)
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: 0xgleb
PR: #1911
File: crates/subgraph/src/utils/mod.rs:1-1
Timestamp: 2025-07-21T16:37:20.599Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb prefers explicit module imports over re-exporting symbols at higher levels. Specifically for the float constants in crates/subgraph/src/utils/float.rs, they prefer using utils::float::* rather than re-exporting with pub use float::* in the utils module, as the explicit import makes it clearer what is being imported and why it's needed.
Learnt from: 0xgleb
PR: #1859
File: crates/quote/src/quote_debug.rs:472-492
Timestamp: 2025-05-20T10:20:08.206Z
Learning: In the Rain Orderbook codebase, the #[tokio::test(flavor = "multi_thread")] annotation is specifically needed for tests that use LocalEvm, not just for consistency across all async tests.
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:69-127
Timestamp: 2025-05-27T06:16:35.738Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, directly accessing internal RwLock state in tests using notice.0.read().unwrap() is acceptable and does not require encapsulation through public getter methods.
Learnt from: 0xgleb
PR: #1911
File: crates/common/src/raindex_client/orders.rs:720-720
Timestamp: 2025-07-21T16:34:04.947Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb prefers using .unwrap() in test code rather than .expect() with descriptive messages, considering the direct unwrap approach acceptable for test contexts where failures should be fast and clear.
Learnt from: findolor
PR: #1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.511Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: findolor
PR: #1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using #[cfg(target_family = "wasm")] and #[cfg(not(target_family = "wasm"))], and don't require additional wasm_bindgen_test_configure!(run_in_browser) directives.
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:87-114
Timestamp: 2025-05-27T06:16:12.195Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, testing one WriteTransactionStatus variant (like PendingPrepare) is sufficient for the update_status_and_emit method since all variants follow the same code path through the From<WriteTransactionStatus> implementation.
Learnt from: 0xgleb
PR: #1844
File: tauri-app/src-tauri/src/commands/wallet.rs:27-28
Timestamp: 2025-05-16T17:24:34.724Z
Learning: In Rust projects, dependencies listed in the [dependencies] section of Cargo.toml are available for both application code and tests. The tokio crate with the "full" feature set includes the "test" feature needed for #[tokio::test] to work properly.
crates/js_api/src/gui/mod.rs (8)
Learnt from: findolor
PR: #1903
File: crates/cli/src/commands/order/calldata.rs:47-57
Timestamp: 2025-06-17T16:46:19.035Z
Learning: In the CLI command crates/cli/src/commands/order/calldata.rs, the user prefers to let lower-level errors from try_into_call() bubble up when the RPCs list is empty, rather than adding early validation checks with custom error messages.
Learnt from: findolor
PR: #1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.511Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Learnt from: findolor
PR: #1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The wasm_bindgen_utils crate in the Rain Orderbook project handles conditional compilation for JsValue and JsError internally, allowing impl From<Error> for JsValue to work on non-WASM targets without explicit cfg guards.
Learnt from: findolor
PR: #1463
File: crates/settings/src/yaml/context.rs:298-304
Timestamp: 2025-03-28T10:09:10.696Z
Learning: In the resolve_token_path method of the Context implementation in crates/settings/src/yaml/context.rs, when an unknown property is accessed on a token, it returns a ContextError::InvalidPath error, not a ContextError::PropertyNotFound error.
Learnt from: findolor
PR: #1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: KeyNotFound(String) for when a specific YAML key is not found in a hash/map, and NotFound(String) for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: #1983
File: crates/settings/src/gui.rs:965-973
Timestamp: 2025-07-11T08:37:24.423Z
Learning: In the rainlanguage/rain.orderbook project, user findolor prefers to keep user-facing error messages generic and user-friendly rather than technically specific. For example, using "a valid number" instead of "a valid u8 (0-255)" in GUI validation error messages to maintain simplicity for end users.
packages/ui-components/tsconfig.json (10)
Learnt from: rouzwelt
PR: #1955
File: packages/orderbook/package.json:40-40
Timestamp: 2025-07-01T21:26:42.195Z
Learning: In the rain.orderbook project, the team does not require cross-platform compatibility improvements for the TypeScript check script in packages/orderbook/package.json. The current brace expansion syntax "./dist/**/*.{ts,js}" is sufficient for their development environment.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: findolor
PR: #1936
File: packages/ui-components/vite.config.ts:21-23
Timestamp: 2025-06-17T14:55:22.914Z
Learning: In the rain.orderbook project, the Vite configuration uses 'import.meta.vitest': 'undefined' (as a string) combined with conditional if (import.meta.vitest) checks for in-source testing. The mock files are excluded from test execution using exclude: ['src/lib/__mocks__/**/*.ts']. This configuration successfully allows dev builds to work without vi undefined errors, despite the theoretical expectation that the string "undefined" would be truthy and cause issues.
Learnt from: hardingjam
PR: #1515
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/layout.test.ts:37-37
Timestamp: 2025-03-26T16:16:51.943Z
Learning: For Rain Orderbook projects, in test files, the preference is to use "as any" type assertions with per-line ESLint disable comments rather than creating dedicated types for test parameters.
Learnt from: findolor
PR: #1926
File: packages/ui-components/src/lib/mocks/stores.ts:13-17
Timestamp: 2025-06-30T14:17:16.626Z
Learning: User findolor reports that vi.mock(import('@rainlanguage/orderbook'), async (importOriginal) => { ... }) syntax works in their testing environment, despite official Vitest documentation indicating the first argument should be a string. This suggests there may be specific Vitest versions or configurations that support dynamic import() as the first argument to vi.mock().
Learnt from: hardingjam
PR: #1705
File: packages/webapp/src/routes/deploy/page.test.ts:80-81
Timestamp: 2025-04-28T15:38:30.561Z
Learning: For this codebase, explicit any type assertions are considered acceptable in test files, as confirmed by the repository owner.
Learnt from: findolor
PR: #1971
File: packages/orderbook/package.json:45-46
Timestamp: 2025-07-09T18:31:46.308Z
Learning: In the rain.orderbook project, maintainer findolor prefers to keep TypeDoc dependencies with caret version ranges (e.g., "^0.28.7") rather than pinning to exact versions, even when this might cause unstable HTML output and noisy diffs in generated documentation.
Learnt from: hardingjam
PR: #1597
File: packages/ui-components/src/tests/OrderDetail.test.ts:120-120
Timestamp: 2025-04-08T09:18:46.653Z
Learning: In test files for the Rain Orderbook project, it's acceptable to bypass TypeScript's strict typing using constructs like as unknown as [Type] to create simplified mock objects that don't need to implement the entire interface.
Learnt from: hardingjam
PR: #1516
File: packages/webapp/src/routes/deploy/[strategyName]/layout.test.ts:0-0
Timestamp: 2025-03-26T15:00:17.997Z
Learning: For Rain Orderbook projects, there's a preference not to include tests for SvelteKit methods (like parent function rejections) in test files, as these are considered framework responsibilities rather than application code that needs testing.
Learnt from: hardingjam
PR: #1724
File: packages/ui-components/src/tests/ButtonDarkMode.test.ts:1-54
Timestamp: 2025-05-03T10:29:04.009Z
Learning: JSDoc comments are not considered necessary for test files in the rainlanguage/rain.orderbook repository. Test descriptions and assertions are sufficient documentation.
crates/common/src/raindex_client/mod.rs (14)
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: #1941
File: crates/js_api/src/raindex/vaults.rs:175-181
Timestamp: 2025-06-20T07:51:08.790Z
Learning: In the RaindexClient vault methods, &self parameters are intentionally kept for API consistency to make all vault operations instance methods, even when the methods don't use client state. This is a design preference for maintaining a uniform interface.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: 0xgleb
PR: #1911
File: crates/subgraph/src/utils/mod.rs:1-1
Timestamp: 2025-07-21T16:37:20.599Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb prefers explicit module imports over re-exporting symbols at higher levels. Specifically for the float constants in crates/subgraph/src/utils/float.rs, they prefer using utils::float::* rather than re-exporting with pub use float::* in the utils module, as the explicit import makes it clearer what is being imported and why it's needed.
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
crates/common/src/transaction.rs (8)
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:87-114
Timestamp: 2025-05-27T06:16:12.195Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, testing one WriteTransactionStatus variant (like PendingPrepare) is sufficient for the update_status_and_emit method since all variants follow the same code path through the From<WriteTransactionStatus> implementation.
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:69-127
Timestamp: 2025-05-27T06:16:35.738Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, directly accessing internal RwLock state in tests using notice.0.read().unwrap() is acceptable and does not require encapsulation through public getter methods.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: 0xgleb
PR: #1911
File: crates/subgraph/src/types/impls.rs:7-15
Timestamp: 2025-07-21T16:34:31.193Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb considers breaking changes that remove unsafe default behaviors to be intentional and acceptable. Specifically, the get_decimals() method in crates/subgraph/src/types/impls.rs was intentionally changed to return MissingDecimals error instead of defaulting to 18 decimals, as defaulting to 18 is considered unsafe and should never have been done.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: findolor
PR: #1903
File: crates/cli/src/commands/order/calldata.rs:47-57
Timestamp: 2025-06-17T16:46:19.035Z
Learning: In the CLI command crates/cli/src/commands/order/calldata.rs, the user prefers to let lower-level errors from try_into_call() bubble up when the RPCs list is empty, rather than adding early validation checks with custom error messages.
packages/ui-components/src/lib/types/transaction.ts (6)
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the queryKey property is intentionally declared in both InternalTransactionArgs and TransactionArgs types. This duplication should be kept as per the project's design preferences.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/tests/transactionStore.test.ts:3-5
Timestamp: 2025-05-19T17:16:54.732Z
Learning: In the rain.orderbook project, there is an ongoing migration of transaction handling from the legacy transactionStore to a new TransactionManager. TransactionStatusMessage has been moved to lib/types/transaction.ts, while TransactionErrorMessage is still in transactionStore but will be moved once other transactions are migrated.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
crates/common/src/withdraw.rs (6)
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:87-114
Timestamp: 2025-05-27T06:16:12.195Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, testing one WriteTransactionStatus variant (like PendingPrepare) is sufficient for the update_status_and_emit method since all variants follow the same code path through the From<WriteTransactionStatus> implementation.
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:69-127
Timestamp: 2025-05-27T06:16:35.738Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, directly accessing internal RwLock state in tests using notice.0.read().unwrap() is acceptable and does not require encapsulation through public getter methods.
Learnt from: 0xgleb
PR: #1911
File: crates/subgraph/src/types/impls.rs:7-15
Timestamp: 2025-07-21T16:34:31.193Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb considers breaking changes that remove unsafe default behaviors to be intentional and acceptable. Specifically, the get_decimals() method in crates/subgraph/src/types/impls.rs was intentionally changed to return MissingDecimals error instead of defaulting to 18 decimals, as defaulting to 18 is considered unsafe and should never have been done.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
packages/ui-components/src/lib/types/vaults.ts (13)
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the queryKey property is intentionally declared in both InternalTransactionArgs and TransactionArgs types. This duplication should be kept as per the project's design preferences.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1597
File: packages/ui-components/src/tests/OrderDetail.test.ts:120-120
Timestamp: 2025-04-08T09:18:46.653Z
Learning: In test files for the Rain Orderbook project, it's acceptable to bypass TypeScript's strict typing using constructs like as unknown as [Type] to create simplified mock objects that don't need to implement the entire interface.
Learnt from: hardingjam
PR: #1575
File: packages/webapp/src/routes/deploy/layout.test.ts:28-37
Timestamp: 2025-04-07T07:50:17.023Z
Learning: In the rain.orderbook repository, the team considers it acceptable to use type assertions (like as any) for complex types in test files. This is preferred over creating detailed type definitions that would only be used for testing.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:50-54
Timestamp: 2025-06-07T05:19:04.767Z
Learning: In the rainlanguage/rain.orderbook codebase, the team prefers pragmatic code approaches over strict TypeScript patterns when the current implementation is sufficient for their use case, such as using if (result.error) instead of if ('error' in result) for discriminated union type checking.
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
crates/js_api/src/lib.rs (9)
Learnt from: findolor
PR: #1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like #[cfg(target_family = "wasm")] should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: findolor
PR: #1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: findolor
PR: #1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The wasm_bindgen_utils crate in the Rain Orderbook project handles conditional compilation for JsValue and JsError internally, allowing impl From<Error> for JsValue to work on non-WASM targets without explicit cfg guards.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using #[cfg(target_family = "wasm")] and #[cfg(not(target_family = "wasm"))], and don't require additional wasm_bindgen_test_configure!(run_in_browser) directives.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
Learnt from: findolor
PR: #1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.511Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: findolor
PR: #1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
Learnt from: 0xgleb
PR: #1846
File: crates/quote/src/quote.rs:309-317
Timestamp: 2025-05-20T15:34:06.751Z
Learning: In Rust, when importing from the alloy crate, use alloy::hex; imports the hex macro, not a module, so it can't be consolidated with imports like use alloy::hex::ToHex; using the grouped import syntax.
packages/ui-components/src/__tests__/OrderDetail.test.ts (33)
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: findolor
PR: #1907
File: packages/orderbook/test/common/test.test.ts:75-77
Timestamp: 2025-06-04T10:21:01.388Z
Learning: The DotrainOrder.create API in packages/orderbook/test/common/test.test.ts is internal and not used directly in consumer applications, so API changes here don't require external breaking change documentation.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: #1974
File: packages/ui-components/src/tests/DeploymentSteps.test.ts:123-126
Timestamp: 2025-07-09T12:35:45.699Z
Learning: In packages/ui-components/src/tests/DeploymentSteps.test.ts, findolor prefers to keep mock initializations (like setSelectToken) in individual test cases rather than consolidating them into shared beforeEach blocks, even when it results in duplication.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:125-143
Timestamp: 2025-04-08T12:56:03.272Z
Learning: The OrderDetail component in the Rain orderbook UI doesn't currently have error handling tests, but issue #1605 has been created to address this in the future.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: hardingjam
PR: #1494
File: packages/ui-components/src/tests/WalletProvider.test.ts:18-28
Timestamp: 2025-03-24T12:27:07.862Z
Learning: In the WalletProvider tests, verifying that setAccountContext is called with the correct store is sufficient. Additional testing of Svelte's store implementation (like subscribing to verify the store value) is unnecessary as it would just be testing the framework itself.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: thedavidmeister
PR: #1926
File: test/concrete/ob/OrderBook.clear.zeroAmount.t.sol:24-32
Timestamp: 2025-06-16T10:49:47.770Z
Learning: LibTestAddOrder.conformConfig() in test/util/lib/LibTestAddOrder.sol automatically constrains OrderConfigV3 to prevent common test failures by ensuring validInputs[0].token != validOutputs[0].token, setting them to address(0) and address(1) respectively if they're equal. This prevents TokenSelfTrade errors in fuzz tests.
Learnt from: findolor
PR: #1469
File: packages/ui-components/src/tests/CodeMirrorDotrain.test.ts:75-98
Timestamp: 2025-03-31T10:16:53.544Z
Learning: In the rainlanguage/rain.orderbook project, direct manipulation of Svelte's internal state (component.$$.ctx) in tests is an acceptable approach for testing component behavior, as demonstrated in the CodeMirrorDotrain tests.
Learnt from: hardingjam
PR: #1565
File: packages/webapp/src/routes/deploy/layout.test.ts:12-29
Timestamp: 2025-04-07T08:18:36.473Z
Learning: In test files for this project, hardingjam prefers to use custom mocks (such as for localStorage) rather than relying on environment-provided implementations, as this allows for spying on individual methods and having precise control over implementation details for more robust testing.
Learnt from: hardingjam
PR: #1494
File: packages/ui-components/src/lib/providers/wallet/useAccount.ts:9-14
Timestamp: 2025-03-24T08:36:15.819Z
Learning: The useAccount hook in the wallet provider implementation returns an object rather than a direct value to support future extensibility. It's expected to eventually include properties like connected and methods like disconnect() beyond just the account address.
Learnt from: hardingjam
PR: #1669
File: packages/webapp/src/routes/+layout.ts:82-261
Timestamp: 2025-04-15T12:35:56.008Z
Learning: When testing Svelte applications, focus on application logic rather than testing Svelte's built-in reactive store system. Testing framework functionality (like Svelte's store reactivity) is generally unnecessary in application tests.
Learnt from: hardingjam
PR: #1516
File: packages/webapp/src/routes/deploy/[strategyName]/layout.test.ts:0-0
Timestamp: 2025-03-26T15:00:17.997Z
Learning: For Rain Orderbook projects, there's a preference not to include tests for SvelteKit methods (like parent function rejections) in test files, as these are considered framework responsibilities rather than application code that needs testing.
Learnt from: findolor
PR: #1917
File: tauri-app/src/lib/stores/order.ts:10-15
Timestamp: 2025-06-11T11:27:14.391Z
Learning: In this codebase, Svelte writable/derived stores (e.g., subgraph in tauri-app/src/lib/stores/settings.ts) expose a custom asynchronous .load() helper that retrieves the current value, so calls like await subgraph.load() are valid.
Learnt from: findolor
PR: #1936
File: packages/ui-components/vite.config.ts:21-23
Timestamp: 2025-06-17T14:55:22.914Z
Learning: In the rain.orderbook project, the Vite configuration uses 'import.meta.vitest': 'undefined' (as a string) combined with conditional if (import.meta.vitest) checks for in-source testing. The mock files are excluded from test execution using exclude: ['src/lib/__mocks__/**/*.ts']. This configuration successfully allows dev builds to work without vi undefined errors, despite the theoretical expectation that the string "undefined" would be truthy and cause issues.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: hardingjam
PR: #1597
File: packages/ui-components/src/tests/OrderDetail.test.ts:120-120
Timestamp: 2025-04-08T09:18:46.653Z
Learning: In test files for the Rain Orderbook project, it's acceptable to bypass TypeScript's strict typing using constructs like as unknown as [Type] to create simplified mock objects that don't need to implement the entire interface.
Learnt from: findolor
PR: #1891
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/page.test.ts:66-80
Timestamp: 2025-06-08T18:43:51.842Z
Learning: In the rain.orderbook webapp test files, when mocking objects like the transaction manager, it's acceptable to use simple empty objects with @ts-expect-error comments rather than providing complete mock implementations with all properties and methods.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:50-54
Timestamp: 2025-06-07T05:19:04.767Z
Learning: In the rainlanguage/rain.orderbook codebase, the team prefers pragmatic code approaches over strict TypeScript patterns when the current implementation is sufficient for their use case, such as using if (result.error) instead of if ('error' in result) for discriminated union type checking.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/tests/VaultDetail.test.ts:177-181
Timestamp: 2025-07-04T09:14:35.748Z
Learning: In the rain.orderbook project, maintainer findolor is fine with mutating mock data directly in test files using @ts-expect-error comments, preferring this pragmatic approach over immutable patterns like spread operators for test data updates.
Learnt from: findolor
PR: #1926
File: packages/ui-components/src/lib/mocks/stores.ts:13-17
Timestamp: 2025-06-30T14:17:16.626Z
Learning: User findolor reports that vi.mock(import('@rainlanguage/orderbook'), async (importOriginal) => { ... }) syntax works in their testing environment, despite official Vitest documentation indicating the first argument should be a string. This suggests there may be specific Vitest versions or configurations that support dynamic import() as the first argument to vi.mock().
Learnt from: hardingjam
PR: #1515
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/layout.test.ts:37-37
Timestamp: 2025-03-26T16:16:51.943Z
Learning: For Rain Orderbook projects, in test files, the preference is to use "as any" type assertions with per-line ESLint disable comments rather than creating dedicated types for test parameters.
Learnt from: findolor
PR: #2001
File: crates/common/src/raindex_client/vaults.rs:0-0
Timestamp: 2025-07-16T14:33:45.887Z
Learning: In the rainlanguage/rain.orderbook codebase, findolor considers using Address::random() in tests to be acceptable when the mock server doesn't validate the address parameter and returns a fixed response, making the test deterministic regardless of the address value used.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use enabled: true rather than Object.keys($activeSubgraphs).length > 0 because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: hardingjam
PR: #1705
File: packages/ui-components/src/tests/InputRegistryUrl.test.ts:70-95
Timestamp: 2025-04-29T11:10:15.504Z
Learning: When testing time-dependent states like loading indicators in UI components, userEvent.click() is preferred over fireEvent.click() as it provides a more realistic simulation of user behavior, especially when used with fake timers.
packages/webapp/src/lib/services/modal.ts (14)
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:33-33
Timestamp: 2025-05-20T12:01:28.391Z
Learning: In the rain.orderbook project, transaction success handling in modal components is managed by the TransactionModal component and listeners that handle adding toasts, rather than directly invoking callbacks. This is part of the architecture being refactored as transactions are moved to the TransactionManager.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: brusherru
PR: #2002
File: tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte:20-25
Timestamp: 2025-07-24T08:16:47.393Z
Learning: In the Rain OrderBook Tauri app, modal components directly mutate the open prop (setting open = false) as a consistent pattern across the codebase. This approach is maintained for consistency even though it violates typical Svelte one-way data flow, with plans to refactor all modals together in the future rather than making isolated changes.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
packages/ui-components/src/lib/utils/account.ts (2)
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: hardingjam
PR: #1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like string | null.
packages/webapp/src/routes/vaults/+page.svelte (18)
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: brusherru
PR: #2002
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:63-68
Timestamp: 2025-07-24T19:31:29.248Z
Learning: In Svelte components, functions that depend on reactive state and are used in template rendering (like isVaultDisabled in VaultsListTable.svelte) should remain as reactive statements ($:) rather than regular functions, because regular functions won't trigger UI updates when their dependencies change. This is especially important for UI state like disabled/enabled status that needs to update across multiple rendered items when selection state changes.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:33-33
Timestamp: 2025-05-20T12:01:28.391Z
Learning: In the rain.orderbook project, transaction success handling in modal components is managed by the TransactionModal component and listeners that handle adding toasts, rather than directly invoking callbacks. This is part of the architecture being refactored as transactions are moved to the TransactionManager.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: hardingjam
PR: #1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check if (dotrain && deployment) inside onMount is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use enabled: true rather than Object.keys($activeSubgraphs).length > 0 because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
packages/ui-components/src/lib/components/detail/OrderDetail.svelte (38)
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: hardyjosh
PR: #2035
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:167-174
Timestamp: 2025-07-26T06:56:28.207Z
Learning: In OrdersListTable.svelte, maintainer hardyjosh considers keyed each-blocks unnecessary for item.inputs and item.outputs arrays because the entire query result updates at once during refresh, making DOM diffing optimizations negligible when the whole dataset is replaced rather than individual items being modified.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:125-143
Timestamp: 2025-04-08T12:56:03.272Z
Learning: The OrderDetail component in the Rain orderbook UI doesn't currently have error handling tests, but issue #1605 has been created to address this in the future.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: findolor
PR: #1941
File: crates/js_api/src/raindex/vaults.rs:175-181
Timestamp: 2025-06-20T07:51:08.790Z
Learning: In the RaindexClient vault methods, &self parameters are intentionally kept for API consistency to make all vault operations instance methods, even when the methods don't use client state. This is a design preference for maintaining a uniform interface.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: #1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: hardingjam
PR: #1750
File: packages/ui-components/src/lib/types/toast.ts:0-0
Timestamp: 2025-05-15T09:33:54.104Z
Learning: The ToastProps interface in packages/ui-components/src/lib/types/toast.ts intentionally keeps both type ('success', 'error', 'warning', 'info') and color ('green', 'red', 'yellow', 'blue') properties separate to maintain flexibility, even though they have a default one-to-one mapping.
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the queryKey property is intentionally declared in both InternalTransactionArgs and TransactionArgs types. This duplication should be kept as per the project's design preferences.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: findolor
PR: #2012
File: packages/orderbook/test/js_api/dotrainRegistry.test.ts:10-10
Timestamp: 2025-07-23T10:51:18.597Z
Learning: In the rain.orderbook project, maintainer findolor is fine with using typeof void 0 === typeof result.value for undefined checks in test files like packages/orderbook/test/js_api/dotrainRegistry.test.ts, preferring to keep this pattern rather than changing it to result.value === undefined for readability.
Learnt from: brusherru
PR: #2002
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:63-68
Timestamp: 2025-07-24T19:31:29.248Z
Learning: In Svelte components, functions that depend on reactive state and are used in template rendering (like isVaultDisabled in VaultsListTable.svelte) should remain as reactive statements ($:) rather than regular functions, because regular functions won't trigger UI updates when their dependencies change. This is especially important for UI state like disabled/enabled status that needs to update across multiple rendered items when selection state changes.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: hardingjam
PR: #1494
File: packages/ui-components/src/lib/providers/wallet/useAccount.ts:9-14
Timestamp: 2025-03-24T08:36:15.819Z
Learning: The useAccount hook in the wallet provider implementation returns an object rather than a direct value to support future extensibility. It's expected to eventually include properties like connected and methods like disconnect() beyond just the account address.
Learnt from: findolor
PR: #1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:35-37
Timestamp: 2025-06-17T16:25:44.685Z
Learning: In the tauri-app Svelte application, users must navigate to a settings page to modify settings and then return to other pages. This navigation pattern causes page components to be recreated, which naturally refreshes component state derived from settings without requiring reactive statements ($:). Therefore, reactive statements for settings-derived values are unnecessary when the UX flow involves page navigation.
Learnt from: hardingjam
PR: #1876
File: packages/webapp/src/lib/services/resetActiveOrderbookRef.ts:19-20
Timestamp: 2025-05-20T15:15:01.333Z
Learning: In the Rain orderbook project, there is no preferred orderbook when resetting the active orderbook reference, so selecting the first available one (even with non-deterministic object key ordering) is acceptable.
Learnt from: findolor
PR: #1950
File: crates/common/src/raindex_client/orders.rs:301-301
Timestamp: 2025-06-24T13:36:28.797Z
Learning: In the RaindexClient codebase, when Arc::new(RwLock::new(self.clone())) is used (e.g., in get_orders and get_order_by_hash methods), this creates new Arc/RwLock wrappers around a cloned RaindexClient, but the underlying client data is functionally the same. This pattern is used to provide the correct Arc<RwLock> type expected by RaindexOrder::try_from_sg_order() method.
Learnt from: 0xgleb
PR: #1911
File: crates/subgraph/src/vault_balance_changes_query.rs:133-135
Timestamp: 2025-07-23T13:03:40.669Z
Learning: User 0xgleb prefers not to make changes to test code when tests are already passing, even if the code format could be standardized differently. Working test code should be left alone unless there's a functional issue.
Learnt from: findolor
PR: #1917
File: tauri-app/src/lib/stores/order.ts:10-15
Timestamp: 2025-06-11T11:27:14.391Z
Learning: In this codebase, Svelte writable/derived stores (e.g., subgraph in tauri-app/src/lib/stores/settings.ts) expose a custom asynchronous .load() helper that retrieves the current value, so calls like await subgraph.load() are valid.
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/components/transactions/TransactionList.svelte:10-15
Timestamp: 2025-06-05T12:21:16.329Z
Learning: The transactions array in TransactionList.svelte is expected to remain small, so performance optimizations like derived stores for array reversal are not necessary and simpler code is preferred.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:71-77
Timestamp: 2025-05-19T10:39:19.157Z
Learning: In the Rain Orderbook project, orderHash is typed as string (not Hex) in the InternalTransactionArgs interface because it comes from the WASM function getRemoveOrderCalldata which returns a string value. Meanwhile, txHash is typed as Hex since it represents an actual blockchain transaction hash that requires the stricter type.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:50-54
Timestamp: 2025-06-07T05:19:04.767Z
Learning: In the rainlanguage/rain.orderbook codebase, the team prefers pragmatic code approaches over strict TypeScript patterns when the current implementation is sufficient for their use case, such as using if (result.error) instead of if ('error' in result) for discriminated union type checking.
Learnt from: findolor
PR: #1882
File: packages/ui-components/src/lib/types/modal.ts:31-31
Timestamp: 2025-06-07T09:15:27.885Z
Learning: In the rain.orderbook project, toAddress and orderbookAddress are distinct variables serving different purposes: toAddress is used in transaction confirmation modals (particularly for deposits) to represent the transaction recipient, while orderbookAddress is used elsewhere for orderbook-specific logic outside of deposit-related flows.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:71-77
Timestamp: 2025-05-19T10:39:19.157Z
Learning: In the Rain Orderbook project, orderHash is intentionally typed as string (not Hex) in the InternalTransactionArgs interface because it matches the return type of the getRemoveOrderCalldata WASM function which returns Promise<string>. String operations like .slice() are performed on orderHash in the code. Meanwhile, txHash is typed as Hex for blockchain transaction hashes.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
crates/common/src/withdraw_multiple.rs (25)
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:87-114
Timestamp: 2025-05-27T06:16:12.195Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, testing one WriteTransactionStatus variant (like PendingPrepare) is sufficient for the update_status_and_emit method since all variants follow the same code path through the From<WriteTransactionStatus> implementation.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: 0xgleb
PR: #1911
File: crates/subgraph/src/types/impls.rs:7-15
Timestamp: 2025-07-21T16:34:31.193Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb considers breaking changes that remove unsafe default behaviors to be intentional and acceptable. Specifically, the get_decimals() method in crates/subgraph/src/types/impls.rs was intentionally changed to return MissingDecimals error instead of defaulting to 18 decimals, as defaulting to 18 is considered unsafe and should never have been done.
Learnt from: 0xgleb
PR: #1859
File: crates/quote/src/quote_debug.rs:472-492
Timestamp: 2025-05-20T10:20:08.206Z
Learning: In the Rain Orderbook codebase, the #[tokio::test(flavor = "multi_thread")] annotation is specifically needed for tests that use LocalEvm, not just for consistency across all async tests.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: #1874
File: tauri-app/src-tauri/src/transaction_status.rs:69-127
Timestamp: 2025-05-27T06:16:35.738Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, directly accessing internal RwLock state in tests using notice.0.read().unwrap() is acceptable and does not require encapsulation through public getter methods.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: TOTAL=number ADDITIONS=number DELETIONS=number, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any additional text or formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: findolor
PR: #1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:26:31.566Z
Learning: For PR #1884 and future PRs in rainlanguage/rain.orderbook repository, provide PR size reports in a separate comment with ONLY the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number", without any additional text or explanation. Reports should exclude irrelevant files such as lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using #[cfg(target_family = "wasm")] and #[cfg(not(target_family = "wasm"))], and don't require additional wasm_bindgen_test_configure!(run_in_browser) directives.
Learnt from: 0xgleb
PR: #1911
File: crates/common/src/raindex_client/orders.rs:720-720
Timestamp: 2025-07-21T16:34:04.947Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb prefers using .unwrap() in test code rather than .expect() with descriptive messages, considering the direct unwrap approach acceptable for test contexts where failures should be fast and clear.
Learnt from: findolor
PR: #1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like #[cfg(target_family = "wasm")] should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
packages/ui-components/src/lib/providers/transactions/TransactionManager.ts (16)
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:62-70
Timestamp: 2025-06-07T05:19:17.333Z
Learning: In the TransactionManager class, error handling for methods like createWithdrawTransaction() is handled elsewhere in the codebase architecture, so additional try-catch wrapping is not needed at the call site.
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the queryKey property is intentionally declared in both InternalTransactionArgs and TransactionArgs types. This duplication should be kept as per the project's design preferences.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/tests/transactionStore.test.ts:3-5
Timestamp: 2025-05-19T17:16:54.732Z
Learning: In the rain.orderbook project, there is an ongoing migration of transaction handling from the legacy transactionStore to a new TransactionManager. TransactionStatusMessage has been moved to lib/types/transaction.ts, while TransactionErrorMessage is still in transactionStore but will be moved once other transactions are migrated.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: findolor
PR: #1907
File: packages/orderbook/test/common/test.test.ts:75-77
Timestamp: 2025-06-04T10:21:01.388Z
Learning: The DotrainOrder.create API in packages/orderbook/test/common/test.test.ts is internal and not used directly in consumer applications, so API changes here don't require external breaking change documentation.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1831
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:24-35
Timestamp: 2025-05-27T12:20:52.644Z
Learning: In the new TransactionManager architecture introduced in PR #1831, errors are automatically surfaced by the TransactionManager through errToast calls in the error callbacks. Additional try-catch error handling around transaction manager methods like handleRemoveOrder is unnecessary since the manager handles error reporting internally.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: #1903
File: crates/settings/src/yaml/orderbook.rs:371-377
Timestamp: 2025-06-17T16:21:24.384Z
Learning: In crates/settings/src/yaml/orderbook.rs tests, the user findolor considers RPC ordering in Vec assertions to be intentional and not a test brittleness issue. The ordering of RPCs in tests should be preserved as specified.
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: findolor
PR: #1891
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/page.test.ts:66-80
Timestamp: 2025-06-08T18:43:51.842Z
Learning: In the rain.orderbook webapp test files, when mocking objects like the transaction manager, it's acceptable to use simple empty objects with @ts-expect-error comments rather than providing complete mock implementations with all properties and methods.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:71-77
Timestamp: 2025-05-19T10:39:19.157Z
Learning: In the Rain Orderbook project, orderHash is intentionally typed as string (not Hex) in the InternalTransactionArgs interface because it matches the return type of the getRemoveOrderCalldata WASM function which returns Promise<string>. String operations like .slice() are performed on orderHash in the code. Meanwhile, txHash is typed as Hex for blockchain transaction hashes.
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (16)
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:291-303
Timestamp: 2025-05-20T12:05:48.570Z
Learning: The modal closing behavior in the WithdrawModal component is handled by Flowbite's native implementation rather than through component props, making it unnecessary to test the open state changes directly.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: brusherru
PR: #2002
File: tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte:20-25
Timestamp: 2025-07-24T08:16:47.393Z
Learning: In the Rain OrderBook Tauri app, modal components directly mutate the open prop (setting open = false) as a consistent pattern across the codebase. This approach is maintained for consistency even though it violates typical Svelte one-way data flow, with plans to refactor all modals together in the future rather than making isolated changes.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: hardingjam
PR: #1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: #1494
File: packages/ui-components/src/tests/WalletProvider.test.ts:18-28
Timestamp: 2025-03-24T12:27:07.862Z
Learning: In the WalletProvider tests, verifying that setAccountContext is called with the correct store is sufficient. Additional testing of Svelte's store implementation (like subscribing to verify the store value) is unnecessary as it would just be testing the framework itself.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
packages/webapp/src/lib/services/handleMultipleVaultsWithdraw.ts (23)
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/tests/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: #1956
File: crates/common/src/raindex_client/mod.rs:116-135
Timestamp: 2025-07-04T10:26:24.289Z
Learning: In crates/common/src/raindex_client/mod.rs, the get_multi_subgraph_args method intentionally treats Some(empty vector) the same as None for chain_ids parameter. Both cases should return all networks to support UI behavior where no selection or empty selection means "show all networks". Only when specific chain IDs are provided should the results be filtered.
Learnt from: hardingjam
PR: #1896
File: tauri-app/src/lib/services/executeWalletConnectOrder.ts:41-45
Timestamp: 2025-05-27T12:01:51.647Z
Learning: In the tauri-app codebase, the formatEthersTransactionErrorFn function already handles error formatting appropriately for toast messages in executeWalletConnectOrder, so additional granular error handling based on error types is not needed.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: hardingjam
PR: #1565
File: packages/webapp/src/tests/registryManager.test.ts:227-238
Timestamp: 2025-04-09T13:00:24.640Z
Learning: In the rain.orderbook project, error handling was added to the RegistryManager to handle localStorage exceptions, addressing part of the verification agent's suggestions. The team should also consider testing extremely long URLs that might approach browser limits.
Learnt from: findolor
PR: #1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: thedavidmeister
PR: #1926
File: test/concrete/ob/OrderBook.clear.zeroAmount.t.sol:24-32
Timestamp: 2025-06-16T10:49:47.770Z
Learning: LibTestAddOrder.conformConfig() in test/util/lib/LibTestAddOrder.sol automatically constrains OrderConfigV3 to prevent common test failures by ensuring validInputs[0].token != validOutputs[0].token, setting them to address(0) and address(1) respectively if they're equal. This prevents TokenSelfTrade errors in fuzz tests.
Learnt from: findolor
PR: #1903
File: crates/settings/src/yaml/orderbook.rs:371-377
Timestamp: 2025-06-17T16:21:24.384Z
Learning: In crates/settings/src/yaml/orderbook.rs tests, the user findolor considers RPC ordering in Vec assertions to be intentional and not a test brittleness issue. The ordering of RPCs in tests should be preserved as specified.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: #1983
File: crates/settings/src/gui.rs:965-973
Timestamp: 2025-07-11T08:37:24.423Z
Learning: In the rainlanguage/rain.orderbook project, user findolor prefers to keep user-facing error messages generic and user-friendly rather than technically specific. For example, using "a valid number" instead of "a valid u8 (0-255)" in GUI validation error messages to maintain simplicity for end users.
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: #1941
File: crates/js_api/src/raindex/vaults.rs:175-181
Timestamp: 2025-06-20T07:51:08.790Z
Learning: In the RaindexClient vault methods, &self parameters are intentionally kept for API consistency to make all vault operations instance methods, even when the methods don't use client state. This is a design preference for maintaining a uniform interface.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:33-33
Timestamp: 2025-05-20T12:01:28.391Z
Learning: In the rain.orderbook project, transaction success handling in modal components is managed by the TransactionModal component and listeners that handle adding toasts, rather than directly invoking callbacks. This is part of the architecture being refactored as transactions are moved to the TransactionManager.
packages/webapp/src/routes/orders/[chainId]-[orderbook]-[orderHash]/+page.svelte (14)
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: brusherru
PR: #2002
File: tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte:20-25
Timestamp: 2025-07-24T08:16:47.393Z
Learning: In the Rain OrderBook Tauri app, modal components directly mutate the open prop (setting open = false) as a consistent pattern across the codebase. This approach is maintained for consistency even though it violates typical Svelte one-way data flow, with plans to refactor all modals together in the future rather than making isolated changes.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: findolor
PR: #1883
File: packages/webapp/src/lib/services/handleDeploy.ts:6-16
Timestamp: 2025-05-27T09:47:45.608Z
Learning: In the rain.orderbook webapp, error handling for modal operations like handleDeployModal and handleDisclaimerModal is handled elsewhere in the codebase, not at the individual function level in handleDeploy-type functions.
Learnt from: findolor
PR: #1913
File: Cargo.toml:55-55
Timestamp: 2025-06-06T16:38:04.182Z
Learning: In rain.orderbook repository, during PR chains involving dependency updates, wasm-bindgen-utils may temporarily point to git commits that don't contain the full required functionality, with the understanding that subsequent PRs in the chain will update it to the correct commit.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:33-33
Timestamp: 2025-05-20T12:01:28.391Z
Learning: In the rain.orderbook project, transaction success handling in modal components is managed by the TransactionModal component and listeners that handle adding toasts, rather than directly invoking callbacks. This is part of the architecture being refactored as transactions are moved to the TransactionManager.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: findolor
PR: #1469
File: packages/ui-components/src/tests/CodeMirrorDotrain.test.ts:75-98
Timestamp: 2025-03-31T10:16:53.544Z
Learning: In the rainlanguage/rain.orderbook project, direct manipulation of Svelte's internal state (component.$$.ctx) in tests is an acceptable approach for testing component behavior, as demonstrated in the CodeMirrorDotrain tests.
Learnt from: hardingjam
PR: #1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check if (dotrain && deployment) inside onMount is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
crates/common/src/raindex_client/orders.rs (16)
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: #1941
File: crates/js_api/src/raindex/vaults.rs:175-181
Timestamp: 2025-06-20T07:51:08.790Z
Learning: In the RaindexClient vault methods, &self parameters are intentionally kept for API consistency to make all vault operations instance methods, even when the methods don't use client state. This is a design preference for maintaining a uniform interface.
Learnt from: findolor
PR: #1950
File: crates/common/src/raindex_client/orders.rs:301-301
Timestamp: 2025-06-24T13:36:28.797Z
Learning: In the RaindexClient codebase, when Arc::new(RwLock::new(self.clone())) is used (e.g., in get_orders and get_order_by_hash methods), this creates new Arc/RwLock wrappers around a cloned RaindexClient, but the underlying client data is functionally the same. This pattern is used to provide the correct Arc<RwLock> type expected by RaindexOrder::try_from_sg_order() method.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
Learnt from: findolor
PR: #1913
File: Cargo.toml:55-55
Timestamp: 2025-06-06T16:38:04.182Z
Learning: In rain.orderbook repository, during PR chains involving dependency updates, wasm-bindgen-utils may temporarily point to git commits that don't contain the full required functionality, with the understanding that subsequent PRs in the chain will update it to the correct commit.
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: findolor
PR: #1838
File: crates/cli/src/output.rs:29-41
Timestamp: 2025-05-19T07:14:24.219Z
Learning: For the rainlanguage/rain.orderbook repository, findolor prefers minimal documentation for straightforward functions like output in crates/cli/src/output.rs where the implementation is self-explanatory.
Learnt from: findolor
PR: #1903
File: crates/js_api/src/gui/order_operations.rs:124-134
Timestamp: 2025-06-17T16:32:04.554Z
Learning: In the rain.orderbook codebase, RPC lists are typically small (2 items maximum), so performance optimizations around cloning and converting small Vec collections are generally unnecessary.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: findolor
PR: #1956
File: crates/common/src/raindex_client/trades.rs:215-223
Timestamp: 2025-07-04T10:24:56.163Z
Learning: In the rain.orderbook codebase, the get_trade_count method implementation that fetches all trades to count them is intentionally consistent with previous implementations and not considered a performance issue, as indicated by findolor for the trades counting functionality in crates/common/src/raindex_client/trades.rs.
Learnt from: findolor
PR: #1956
File: crates/common/src/raindex_client/orders.rs:609-609
Timestamp: 2025-07-04T10:27:22.544Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor prefers not to implement overflow protection for trades count casting (usize to u16) at this time, considering it unnecessary for the current scope since the practical risk of orders having 65,535+ trades is extremely low.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
crates/common/src/raindex_client/vaults_list.rs (25)
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: #1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The wasm_bindgen_utils crate in the Rain Orderbook project handles conditional compilation for JsValue and JsError internally, allowing impl From<Error> for JsValue to work on non-WASM targets without explicit cfg guards.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: #1941
File: crates/js_api/src/raindex/vaults.rs:175-181
Timestamp: 2025-06-20T07:51:08.790Z
Learning: In the RaindexClient vault methods, &self parameters are intentionally kept for API consistency to make all vault operations instance methods, even when the methods don't use client state. This is a design preference for maintaining a uniform interface.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: findolor
PR: #1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like #[cfg(target_family = "wasm")] should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: 0xgleb
PR: #1911
File: crates/subgraph/src/types/impls.rs:7-15
Timestamp: 2025-07-21T16:34:31.193Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb considers breaking changes that remove unsafe default behaviors to be intentional and acceptable. Specifically, the get_decimals() method in crates/subgraph/src/types/impls.rs was intentionally changed to return MissingDecimals error instead of defaulting to 18 decimals, as defaulting to 18 is considered unsafe and should never have been done.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1860
File: packages/ui-components/src/lib/stores/transactionStore.ts:130-136
Timestamp: 2025-05-19T18:24:17.608Z
Learning: In the rain.orderbook project, the awaitSubgraphIndexing function has a two-step validation process: it first checks that data.value from WasmEncodedResult exists, and only then applies the isSuccess predicate. This makes a simple truthiness check (!!data) sufficient in the isSuccess predicate since the value has already been pre-validated.
Learnt from: findolor
PR: #1721
File: crates/js_api/src/bindings/mod.rs:1-131
Timestamp: 2025-05-01T14:39:53.795Z
Learning: Empty input validation for functions like keccak256 and get_order_hash in the WebAssembly bindings is not required as empty inputs are considered valid in this context.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: findolor
PR: #1903
File: crates/common/src/deposit.rs:63-64
Timestamp: 2025-06-17T16:54:43.176Z
Learning: In the rain.orderbook codebase, the maintainer findolor prefers to keep the current implementation that clones the rpcs vector when calling ReadableClient::new_from_urls rather than optimizing it to avoid the clone or adding early validation for empty rpcs. Performance micro-optimizations like avoiding vector clones in this context are not a priority.
Learnt from: findolor
PR: #1903
File: crates/cli/src/commands/order/calldata.rs:47-57
Timestamp: 2025-06-17T16:46:19.035Z
Learning: In the CLI command crates/cli/src/commands/order/calldata.rs, the user prefers to let lower-level errors from try_into_call() bubble up when the RPCs list is empty, rather than adding early validation checks with custom error messages.
Learnt from: findolor
PR: #1903
File: crates/js_api/src/gui/order_operations.rs:124-134
Timestamp: 2025-06-17T16:32:04.554Z
Learning: In the rain.orderbook codebase, RPC lists are typically small (2 items maximum), so performance optimizations around cloning and converting small Vec collections are generally unnecessary.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: findolor
PR: #1458
File: packages/orderbook/test/js_api/gui.test.ts:1069-1072
Timestamp: 2025-03-27T10:22:32.081Z
Learning: It's acceptable to use @ts-expect-error comments to bypass TypeScript type checking for WASM return values when there are type mismatches between WebAssembly outputs and TypeScript interfaces, rather than modifying the type definitions or implementing conversion layers.
Learnt from: findolor
PR: #1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using #[cfg(target_family = "wasm")] and #[cfg(not(target_family = "wasm"))], and don't require additional wasm_bindgen_test_configure!(run_in_browser) directives.
Learnt from: findolor
PR: #1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
Learnt from: 0xgleb
PR: #1713
File: crates/settings/src/remote/chains/mod.rs:43-226
Timestamp: 2025-05-13T20:06:22.602Z
Learning: When writing tests for collections of complex objects in Rust, prefer item-by-item comparison over direct vector comparison to get more specific error messages that pinpoint exactly which item and field has a mismatch.
packages/ui-components/src/lib/components/tables/VaultsListTable.svelte (41)
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:60-60
Timestamp: 2025-06-27T17:34:15.825Z
Learning: In the VaultsListTable.svelte component, the activeAccounts store is redundant in query keys when the owners variable (derived from activeAccountsItems) is already included, as owners is what's actually used in the query function while activeAccounts is just a transformed version of the same data.
Learnt from: brusherru
PR: #2002
File: packages/ui-components/src/lib/components/tables/VaultsListTable.svelte:63-68
Timestamp: 2025-07-24T19:31:29.248Z
Learning: In Svelte components, functions that depend on reactive state and are used in template rendering (like isVaultDisabled in VaultsListTable.svelte) should remain as reactive statements ($:) rather than regular functions, because regular functions won't trigger UI updates when their dependencies change. This is especially important for UI state like disabled/enabled status that needs to update across multiple rendered items when selection state changes.
Learnt from: hardingjam
PR: #1870
File: packages/webapp/src/lib/components/WithdrawModal.svelte:31-31
Timestamp: 2025-05-20T12:03:18.032Z
Learning: The VaultActionArgs type no longer contains an action property after refactoring the deposit/withdraw modals into separate components.
Learnt from: hardyjosh
PR: #2035
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:167-174
Timestamp: 2025-07-26T06:56:28.207Z
Learning: In OrdersListTable.svelte, maintainer hardyjosh considers keyed each-blocks unnecessary for item.inputs and item.outputs arrays because the entire query result updates at once during refresh, making DOM diffing optimizations negligible when the whole dataset is replaced rather than individual items being modified.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: findolor
PR: #1744
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:73-76
Timestamp: 2025-05-09T05:30:02.520Z
Learning: In Rain.orderbook, VaultCalldataResult is a wrapper type that contains both error and value properties. When using this in the DepositOrWithdrawModal component, only the inner value field is passed to the handleTransaction function, not the complete wrapper.
Learnt from: hardingjam
PR: #1651
File: packages/ui-components/src/lib/components/TanstackAppTable.svelte:13-13
Timestamp: 2025-04-10T16:32:51.198Z
Learning: In the TanstackAppTable.svelte component, the queryKey prop should be required (type: string) rather than optional (string | undefined) to ensure proper query invalidation.
Learnt from: findolor
PR: #1996
File: packages/ui-components/src/tests/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/tests/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like VaultIdInformationComponentProps in test files, even when static analysis tools flag this as discouraged practice.
Learnt from: hardingjam
PR: #1512
File: packages/ui-components/src/tests/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an onRemove callback approach instead of the previous handleOrderRemoveModal pattern for order removal functionality, as part of PR #1512.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:74-76
Timestamp: 2025-06-07T05:18:31.404Z
Learning: In vault withdrawal error handling, prefer user-friendly generic error messages over exposing technical error details from getVaultWithdrawCalldata, as the underlying errors are not end user friendly.
Learnt from: hardingjam
PR: #1738
File: packages/ui-components/src/lib/providers/toasts/useToasts.ts:46-52
Timestamp: 2025-05-07T16:51:13.418Z
Learning: UX enhancements for toast notifications, such as pausing timeout on hover, were considered out of scope for the toast refactoring PR.
Learnt from: hardingjam
PR: #1493
File: packages/ui-components/src/tests/DeployButton.test.ts:36-40
Timestamp: 2025-03-28T10:22:11.771Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte doesn't have an explicit disabled prop. Instead, its disabled state is internally controlled by the checkingDeployment variable, which is set to true during deployment checks.
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use enabled: true rather than Object.keys($activeSubgraphs).length > 0 because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: #1883
File: packages/ui-components/src/lib/components/deployment/ButtonSelectOption.svelte:14-14
Timestamp: 2025-05-27T09:46:58.699Z
Learning: In Svelte components, there is no need to conditionally render data-testid attributes to handle empty values. Empty data-testid attributes are acceptable and don't require special handling.
Learnt from: findolor
PR: #1903
File: packages/ui-components/src/lib/components/detail/TanstackOrderQuote.svelte:24-31
Timestamp: 2025-06-17T17:48:58.544Z
Learning: The project maintainer prefers not to use readonly modifiers on component props like rpcUrls: string[] even when they're not mutated, indicating a preference for simpler typing over stricter immutability enforcement in Svelte components.
Learnt from: findolor
PR: #1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:35-37
Timestamp: 2025-06-17T16:25:44.685Z
Learning: In the tauri-app Svelte application, users must navigate to a settings page to modify settings and then return to other pages. This navigation pattern causes page components to be recreated, which naturally refreshes component state derived from settings without requiring reactive statements ($:). Therefore, reactive statements for settings-derived values are unnecessary when the UX flow involves page navigation.
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/components/transactions/TransactionList.svelte:10-15
Timestamp: 2025-06-05T12:21:16.329Z
Learning: The transactions array in TransactionList.svelte is expected to remain small, so performance optimizations like derived stores for array reversal are not necessary and simpler code is preferred.
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: findolor
PR: #1941
File: crates/js_api/src/raindex/vaults.rs:175-181
Timestamp: 2025-06-20T07:51:08.790Z
Learning: In the RaindexClient vault methods, &self parameters are intentionally kept for API consistency to make all vault operations instance methods, even when the methods don't use client state. This is a design preference for maintaining a uniform interface.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any additional text or formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: findolor
PR: #2000
File: crates/common/src/raindex_client/vaults.rs:183-183
Timestamp: 2025-07-16T10:40:05.717Z
Learning: In the rainlanguage/rain.orderbook codebase, user findolor considers breaking changes from Option to U256 for required fields like decimals in RaindexVaultToken to be acceptable and safe, even when they affect multiple usage sites across the codebase.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:26:31.566Z
Learning: For PR #1884 and future PRs in rainlanguage/rain.orderbook repository, provide PR size reports in a separate comment with ONLY the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number", without any additional text or explanation. Reports should exclude irrelevant files such as lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: #1469
File: packages/ui-components/src/tests/CodeMirrorDotrain.test.ts:75-98
Timestamp: 2025-03-31T10:16:53.544Z
Learning: In the rainlanguage/rain.orderbook project, direct manipulation of Svelte's internal state (component.$$.ctx) in tests is an acceptable approach for testing component behavior, as demonstrated in the CodeMirrorDotrain tests.
Learnt from: findolor
PR: #1994
File: crates/common/src/raindex_client/vaults.rs:59-59
Timestamp: 2025-07-16T05:52:05.576Z
Learning: User findolor prefers to handle documentation updates for getter methods in batch via dedicated PRs rather than addressing them individually during feature development, as mentioned for the formatted amount string fields in crates/common/src/raindex_client/vaults.rs.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:25:47.873Z
Learning: After each new commit review for rainlanguage/rain.orderbook repository, generate a PR size report in a separate comment with the format: "TOTAL=number ADDITIONS=number DELETIONS=number". This report should exclude irrelevant files such as lock files (e.g., package-lock.json, cargo.lock).
Learnt from: hardingjam
PR: #1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: findolor
PR: #1599
File: tauri-app/src/routes/orders/add/+page.svelte:287-287
Timestamp: 2025-04-11T06:05:46.473Z
Learning: The ScenarioDebugTable component in tauri-app/src/routes/orders/add/+page.svelte has been designed to manage its own data fetching internally without requiring a chartData prop.
Learnt from: brusherru
PR: #2002
File: tauri-app/src/lib/components/ModalMultipleVaultsWithdraw.svelte:20-25
Timestamp: 2025-07-24T08:16:47.393Z
Learning: In the Rain OrderBook Tauri app, modal components directly mutate the open prop (setting open = false) as a consistent pattern across the codebase. This approach is maintained for consistency even though it violates typical Svelte one-way data flow, with plans to refactor all modals together in the future rather than making isolated changes.
Learnt from: findolor
PR: #1599
File: tauri-app/src/lib/components/ScenarioDebugTable.svelte:46-53
Timestamp: 2025-04-17T08:47:59.930Z
Learning: The ScenarioDebugTable component in tauri-app/src/lib/components/ScenarioDebugTable.svelte has been designed to manage its own data fetching internally without requiring a chartData prop.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/lib/services/handleVaultWithdraw.ts:50-54
Timestamp: 2025-06-07T05:19:04.767Z
Learning: In the rainlanguage/rain.orderbook codebase, the team prefers pragmatic code approaches over strict TypeScript patterns when the current implementation is sufficient for their use case, such as using if (result.error) instead of if ('error' in result) for discriminated union type checking.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: hardingjam
PR: #1565
File: packages/webapp/src/routes/deploy/+layout.svelte:12-16
Timestamp: 2025-04-09T09:59:04.121Z
Learning: In the Rain Orderbook application, a full page reload (window.location.reload()) is needed when changing the registry URL to ensure proper state reinitialization, rather than using SvelteKit's soft navigation methods.
Learnt from: findolor
PR: #1872
File: packages/webapp/src/tests/handleVaultDeposit.test.ts:20-53
Timestamp: 2025-06-07T05:19:46.330Z
Learning: In the rain.orderbook codebase, simple wrapper/adapter functions that just delegate to other functions (like handleVaultDeposit) don't need extensive edge case testing for missing parameters or error handling - the current test coverage focusing on core functionality is sufficient.
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:71-77
Timestamp: 2025-05-19T10:39:19.157Z
Learning: In the Rain Orderbook project, orderHash is intentionally typed as string (not Hex) in the InternalTransactionArgs interface because it matches the return type of the getRemoveOrderCalldata WASM function which returns Promise<string>. String operations like .slice() are performed on orderHash in the code. Meanwhile, txHash is typed as Hex for blockchain transaction hashes.
Learnt from: hardingjam
PR: #1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
Learnt from: hardingjam
PR: #1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:50-74
Timestamp: 2025-04-03T11:29:00.839Z
Learning: In the Rain OrderBook app, error handling for deposit and withdraw actions (including user cancellations and failed transactions) is implemented in the transaction modal component, not in the page-level action handlers.
Learnt from: hardingjam
PR: #1494
File: packages/ui-components/src/lib/providers/wallet/useAccount.ts:9-14
Timestamp: 2025-03-24T08:36:15.819Z
Learning: The useAccount hook in the wallet provider implementation returns an object rather than a direct value to support future extensibility. It's expected to eventually include properties like connected and methods like disconnect() beyond just the account address.
crates/js_api/src/multicall.rs (26)
Learnt from: findolor
PR: #1903
File: crates/cli/src/commands/order/calldata.rs:47-57
Timestamp: 2025-06-17T16:46:19.035Z
Learning: In the CLI command crates/cli/src/commands/order/calldata.rs, the user prefers to let lower-level errors from try_into_call() bubble up when the RPCs list is empty, rather than adding early validation checks with custom error messages.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require #[repr(transparent)] for newtype wrappers in WASM contexts such as AddOrderCalldata and RemoveOrderCalldata as the current implementation is working as expected without it.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Learnt from: findolor
PR: #1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The wasm_bindgen_utils crate in the Rain Orderbook project handles conditional compilation for JsValue and JsError internally, allowing impl From<Error> for JsValue to work on non-WASM targets without explicit cfg guards.
Learnt from: findolor
PR: #1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: #2008
File: crates/common/src/raindex_client/add_orders.rs:85-86
Timestamp: 2025-07-18T10:31:05.498Z
Learning: In the rainlanguage/rain.orderbook codebase, cfg-guarded imports like #[cfg(not(target_family = "wasm"))] use super::*; in test modules are sometimes needed to fix compiler warnings, even when similar imports exist in nested sub-modules. These should not be removed as they serve a specific purpose in the compilation process.
Learnt from: findolor
PR: #1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like #[cfg(target_family = "wasm")] should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: #1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.511Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: 0xgleb
PR: #1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: #1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: thedavidmeister
PR: #1926
File: src/concrete/ob/OrderBook.sol:97-99
Timestamp: 2025-06-16T10:46:39.129Z
Learning: In OrderBook.sol, thedavidmeister prefers error definitions that are self-descriptive when the error condition is specific enough. For ClearZeroAmount, since it only fires when both output amounts are zero, the error name itself provides sufficient context without needing to include the zero values as parameters.
Learnt from: findolor
PR: #1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: #1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: findolor
PR: #1882
File: packages/ui-components/src/lib/types/modal.ts:31-31
Timestamp: 2025-06-07T09:15:27.885Z
Learning: In the rain.orderbook project, toAddress and orderbookAddress are distinct variables serving different purposes: toAddress is used in transaction confirmation modals (particularly for deposits) to represent the transaction recipient, while orderbookAddress is used elsewhere for orderbook-specific logic outside of deposit-related flows.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:101-105
Timestamp: 2025-04-30T10:32:53.866Z
Learning: In the rain.orderbook project, the get_remove_order_calldata function takes SgOrder by value rather than by reference, as per maintainer preference.
Learnt from: findolor
PR: #1938
File: crates/settings/src/yaml/orderbook.rs:185-199
Timestamp: 2025-06-18T19:24:40.518Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers not to refactor get_orderbook_by_network_key to handle multiple orderbooks per network key since their current architecture maintains a one-to-one mapping between orderbooks and networks. They would consider the refactoring if the system evolves to support multiple orderbooks per network in the future.
Learnt from: findolor
PR: #1907
File: packages/orderbook/test/common/test.test.ts:75-77
Timestamp: 2025-06-04T10:21:01.388Z
Learning: The DotrainOrder.create API in packages/orderbook/test/common/test.test.ts is internal and not used directly in consumer applications, so API changes here don't require external breaking change documentation.
Learnt from: findolor
PR: #1646
File: crates/settings/src/scenario.rs:1-1
Timestamp: 2025-04-10T11:08:33.383Z
Learning: Wildcard imports (using *) are acceptable in the rain.orderbook codebase, as per the author's preference.
Learnt from: findolor
PR: #1882
File: packages/webapp/src/lib/services/handleVaultDeposit.ts:96-125
Timestamp: 2025-06-07T09:07:53.733Z
Learning: In the vault deposit flow, vault.token.address is already validated before reaching the approval transaction creation, so casting it to Hex type is safe and doesn't require additional validation.
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/lib/components/ButtonVaultLink.svelte:18-18
Timestamp: 2025-07-04T09:13:39.020Z
Learning: In the RaindexVault type, the vaultId field is a bigint, so bigintToHex should be used instead of bigintStringToHex when converting vault IDs to hex format in UI components.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:71-77
Timestamp: 2025-05-19T10:39:19.157Z
Learning: In the Rain Orderbook project, orderHash is typed as string (not Hex) in the InternalTransactionArgs interface because it comes from the WASM function getRemoveOrderCalldata which returns a string value. Meanwhile, txHash is typed as Hex since it represents an actual blockchain transaction hash that requires the stricter type.
Learnt from: hardingjam
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:71-77
Timestamp: 2025-05-19T10:39:19.157Z
Learning: In the Rain Orderbook project, orderHash is intentionally typed as string (not Hex) in the InternalTransactionArgs interface because it matches the return type of the getRemoveOrderCalldata WASM function which returns Promise<string>. String operations like .slice() are performed on orderHash in the code. Meanwhile, txHash is typed as Hex for blockchain transaction hashes.
Learnt from: findolor
PR: #1706
File: crates/quote/src/js_api/mod.rs:57-61
Timestamp: 2025-04-29T06:19:15.446Z
Learning: In the rain.orderbook codebase, the get_id function is designed to use U256::from_str() rather than U256::from_hex() for parsing order hashes, despite the potential for hex string inputs.
Learnt from: findolor
PR: #1721
File: crates/js_api/src/bindings/mod.rs:1-131
Timestamp: 2025-05-01T14:39:53.795Z
Learning: Empty input validation for functions like keccak256 and get_order_hash in the WebAssembly bindings is not required as empty inputs are considered valid in this context.
Learnt from: findolor
PR: #1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using #[cfg(target_family = "wasm")] and #[cfg(not(target_family = "wasm"))], and don't require additional wasm_bindgen_test_configure!(run_in_browser) directives.
Learnt from: findolor
PR: #1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
🧬 Code Graph Analysis (4)
crates/common/src/raindex_client/mod.rs (3)
crates/common/src/raindex_client/orders.rs (2)
vaults_list(153-155)vaults_list(225-227)crates/subgraph/src/multi_orderbook_client.rs (1)
vaults_list(73-105)crates/subgraph/src/orderbook_client/vault.rs (1)
vaults_list(17-54)
packages/webapp/src/lib/services/modal.ts (2)
packages/webapp/src/lib/services/handleMultipleVaultsWithdraw.ts (1)
WithdrawMultipleModalProps(8-15)packages/ui-components/src/lib/types/modal.ts (1)
TransactionConfirmationProps(16-34)
crates/common/src/withdraw_multiple.rs (1)
crates/common/src/withdraw.rs (4)
execute(34-59)from(21-28)get_withdraw_calldata(61-64)test_withdraw_call_try_into_write_contract_parameters(116-140)
crates/common/src/raindex_client/vaults_list.rs (1)
crates/common/src/raindex_client/mod.rs (6)
new(104-122)to_readable_msg(265-366)from(259-261)from(370-372)from(376-381)get_test_yaml(392-452)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (17)
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: git-clean
- GitHub Check: test
- GitHub Check: test
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: Deploy-Preview
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-artifacts, true)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: Deploy-Docs-Preview
🔇 Additional comments (48)
crates/common/src/lib.rs (1)
21-21: LGTM!The module declaration follows Rust conventions and is properly placed in alphabetical order after the existing
withdrawmodule.packages/ui-components/tsconfig.json (1)
16-22: Good formatting improvement!The multi-line format for the types array enhances readability and makes it easier to maintain. No functional changes, just better formatting.
crates/common/src/transaction.rs (1)
7-7: Excellent centralization of magic numbers!Adding the
TRANSACTION_CONFIRMATIONSconstant improves maintainability by eliminating hardcoded values. The value of 4 confirmations is a reasonable choice for balancing security and speed.packages/ui-components/src/lib/types/transaction.ts (1)
15-15: Well-named enum addition!The
WITHDRAWAL_MULTIPLEenum member follows established naming conventions and provides a clear, user-friendly description for batch vault withdrawal transactions.crates/js_api/src/gui/mod.rs (1)
745-746: LGTM!The error message formatting follows the established pattern and provides user-friendly messaging consistent with the codebase preferences.
crates/js_api/src/lib.rs (2)
6-6: LGTM!The multicall module is correctly added under the WASM conditional compilation guard, following the established pattern for other modules in this file.
7-7: Good consistency improvement.Adding the explicit
#[cfg(target_family = "wasm")]attribute to the yaml module improves consistency with the other module declarations.packages/ui-components/src/lib/types/vaults.ts (1)
1-3: Well-defined type for vault grouping.The
VaultsGroupedByTypetype alias is clearly defined and follows TypeScript best practices with type-only imports and descriptive naming. This provides a solid foundation for the batch vault operations functionality.packages/webapp/src/routes/orders/[chainId]-[orderbook]-[orderHash]/+page.svelte (3)
8-10: Import syntax is correctly implemented.The imports follow the established pattern and correctly use the
$lib/services/syntax as previously suggested.Also applies to: 17-17
62-72: Consistent implementation pattern.The
onWithdrawAllfunction follows the same structure and parameter passing approach as the other handler functions in this file, maintaining consistency and following established architectural patterns for transaction handling.
87-87: LGTM!The
onWithdrawAllprop is correctly passed to the OrderDetail component, following the established pattern for other handler props.crates/common/src/withdraw.rs (3)
39-39: Good use of named constant.Importing and using the
TRANSACTION_CONFIRMATIONSconstant improves code maintainability and consistency across the codebase by replacing magic numbers.
41-41: LGTM!The simplified ledger client handling improves code readability by removing unnecessary tuple unpacking.
49-56: Improved transaction creation.The updates to use the
TRANSACTION_CONFIRMATIONSconstant and accessledger_client.clientimprove consistency and follow the updated API patterns correctly.packages/ui-components/src/__tests__/OrderDetail.test.ts (3)
18-18: LGTM! Mock refactoring aligns with new address utility.The change from mocking
useAccounttoisAddressEqreflects the component's updated approach to address equality checking, which is more focused and testable.Also applies to: 25-27
90-90: Good change to use non-zero balances for withdrawal testing.Using
BigInt(10)andBigInt(20)instead of zero balances makes the test data more realistic for withdrawal scenarios and ensures the withdrawal functionality is properly tested.Also applies to: 108-108
325-348: Excellent test coverage for the new withdraw-all functionality.The test properly verifies that clicking the "withdraw-all-button" triggers the
onWithdrawAllcallback with the complete vaults array, ensuring the batch withdrawal feature works as expected.packages/ui-components/src/lib/utils/account.ts (1)
16-23: LGTM! Well-implemented address equality utility.The function provides excellent defensive programming with proper null/undefined handling, address validation, and error handling. The implementation correctly uses viem utilities and the JSDoc documentation is comprehensive.
packages/webapp/src/routes/vaults/+page.svelte (2)
2-8: LGTM! Proper imports for multi-vault withdrawal functionality.The imports are well-organized and include all necessary dependencies for the batch withdrawal feature, including hooks, service functions, modal handlers, and types.
Also applies to: 17-23
31-41: Excellent implementation following established patterns.The
onWithdrawMultiplefunction correctly delegates to the service layer with all required parameters. The account casting toHexis appropriate, and the simple structure aligns with the established pattern where page-level handlers remain minimal with error handling managed in modal components.packages/webapp/src/lib/services/modal.ts (2)
21-23: LGTM! Modal handler follows established pattern.The
handleWithdrawMultipleModalfunction correctly follows the same instantiation pattern as existing modal handlers, maintaining consistency across the codebase.
25-28: Good refactoring with type alias for better maintainability.Introducing
TransactionConfirmationModalResultas a type alias improves code clarity and makes the return type more maintainable. The update to use this alias is a clean refactor.Also applies to: 32-32
packages/webapp/src/lib/components/WithdrawMultipleModal.svelte (2)
18-25: LGTM! Modal handlers follow established patterns.The
handleSubmitandhandleClosefunctions are implemented correctly, withhandleSubmittriggering the callback before closing the modal, andhandleClosesimply managing the modal state.
55-61: Excellent conditional rendering for wallet connection.The conditional logic properly shows the withdraw button when an account is connected and falls back to the wallet connect component when no account is available, providing a smooth user experience.
packages/ui-components/src/lib/components/detail/OrderDetail.svelte (3)
65-68: LGTM! Clear callback definition for multi-vault withdrawals.The callback signature is well-documented and follows the established pattern of other callbacks in the component.
103-119: Well-structured vault grouping implementation.The vault grouping logic is clean and robust:
- Proper TypeScript typing with explicit
RaindexVaultType- Correct fallback handling with
??operator- Defensive programming with default empty structure fallback
137-159: Robust withdraw button logic with proper filtering.The implementation correctly:
- Filters vaults by ownership using
isAddressEqfor reliable address comparison- Filters out zero-balance vaults
- Shows type-specific withdraw buttons only when multiple vaults exist for that type
- Shows global withdraw button when vaults span multiple types
The logic prevents unnecessary buttons while providing meaningful batch withdrawal options.
crates/common/src/withdraw_multiple.rs (4)
12-13: LGTM! Clean wrapper struct design.The
WithdrawMultipleArgsstruct follows the established pattern in the codebase of using tuple structs for WASM wrappers, maintaining consistency with similar structures.
18-43: Well-implemented execute method following established patterns.The implementation correctly:
- Uses proper conditional compilation for non-WASM targets
- Follows the same pattern as the single withdrawal execute method
- Uses the
TRANSACTION_CONFIRMATIONSconstant (good practice)- Handles errors appropriately with
Resultreturn type- Maintains consistency with existing transaction execution patterns
45-62: Clean and efficient multicall implementation.Both methods are well-implemented:
get_multicallefficiently collects individual withdrawal calldatas into a single multicall structureget_calldataprovides the ABI-encoded bytes for the multicall- Proper async/await usage with error propagation
- Clear separation of concerns between the two methods
72-132: Comprehensive test coverage for batch withdrawal functionality.The tests effectively validate:
- Calldata generation matches expected multicall encoding
- Transaction parameter conversion works correctly
- Proper handling of multiple withdrawal arguments
- Realistic test data with valid addresses and amounts
The test structure follows established patterns and provides good confidence in the implementation.
packages/webapp/src/lib/services/handleMultipleVaultsWithdraw.ts (4)
1-27: LGTM!The imports and type definitions are well-structured and follow established patterns in the codebase. The dependency injection approach through
MultipleVaultsWithdrawHandlerDependenciespromotes testability and loose coupling.
29-50: LGTM!The validation logic is well-implemented with appropriate early returns and user-friendly error messages. The chain validation correctly uses
some()to ensure all vaults are on the same blockchain.
59-84: LGTM!The orderbook validation ensures data consistency for the multicall operation. The error handling properly uses
readableMsgfrom the result wrapper, following the established patterns in the codebase.
86-114: LGTM!The transaction confirmation flow properly integrates with the modal system and transaction manager. Error handling provides appropriate user feedback while maintaining the established patterns in the codebase.
packages/ui-components/src/lib/components/tables/VaultsListTable.svelte (7)
2-2: LGTM!The new imports and prop additions are well-structured. The use of
isAddressEqfor address comparison follows the established pattern for stricter equality checks in the codebase.Also applies to: 7-16, 25-25, 55-57, 59-59
62-89: LGTM!The selection state management is well-implemented. The reactive
isVaultDisabledfunction correctly updates the UI when selection changes, which is essential for the multi-select functionality. The validation logic properly handles empty vaults, ownership restrictions, and cross-chain limitations.
91-98: LGTM!The withdraw all handler correctly clears the selection only after successful withdrawal, which addresses potential UX issues where selections would disappear on user cancellation.
172-194: LGTM!The header UI additions are well-implemented with appropriate conditional rendering and proper button states. The visual design with the withdrawal count and clear button (×) provides good UX for managing selections.
199-201: LGTM!The conditional Select column header maintains proper table structure while only appearing when the multi-select feature is enabled.
213-242: LGTM!The selection cell implementation is comprehensive and well-structured. The conditional rendering, event handling with
stopPropagation, and tooltip feedback for different disabled states provide excellent UX. The empty cell alignment for non-owned vaults maintains proper table structure.
292-292: LGTM!The replacement of the previous address matching utility with
isAddressEqprovides stricter address equality checking and maintains consistency with the selection logic implementation.crates/common/src/raindex_client/orders.rs (3)
2-2: LGTM!The import is correctly placed and follows the module structure.
144-151: LGTM!The helper method correctly filters vaults by type using pattern matching.
217-224: LGTM!The non-wasm implementation correctly mirrors the wasm version, maintaining consistency across targets.
crates/js_api/src/multicall.rs (2)
90-117: LGTM!The error handling implementation follows the project's established patterns for WASM error conversion and provides clear error messages.
122-226: LGTM! Comprehensive test coverageThe test suite thoroughly covers both success and error cases, including edge cases and real-world examples. The tests validate the error message formatting and ensure proper handling of various invalid inputs.
crates/common/src/raindex_client/vaults_list.rs (1)
253-487: Excellent test coverage!The test suite comprehensively covers both native and WASM targets with appropriate mocking, edge cases, and error scenarios. The separation between non-WASM and WASM tests is well-structured.
| /** | ||
| * Creates and initializes a new transaction for withdrawing funds from multiple vaults. | ||
| * @param args - Configuration for the withdrawal transaction. | ||
| * @param args.txHash - Hash of the transaction to track. | ||
| * @param args.chainId - Chain ID where the transaction is being executed. | ||
| * @param args.queryKey - The query key to invalidate, but for multiple vaults withdrawal it's QKEY_VAULTS | ||
| * @param args.vaults - The list of RaindexVault instances from which funds are withdrawn. | ||
| * @returns A new Transaction instance configured for withdrawal. | ||
| * @example | ||
| * const tx = await manager.createWithdrawTransaction({ | ||
| * txHash: '0x123...', | ||
| * chainId: 1, | ||
| * queryKey: '0x789...', // Vault ID | ||
| * entity: sgVaultInstance | ||
| * }); | ||
| */ |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Fix JSDoc example to match the new method.
The JSDoc example still references the old single vault withdrawal method name and parameters. This documentation inconsistency could confuse developers.
Apply this diff to correct the documentation:
- * @example
- * const tx = await manager.createWithdrawTransaction({
- * txHash: '0x123...',
- * chainId: 1,
- * queryKey: '0x789...', // Vault ID
- * entity: sgVaultInstance
- * });
+ * @example
+ * const tx = await manager.createMultipleVaultsWithdrawTransaction({
+ * txHash: '0x123...',
+ * chainId: 1,
+ * queryKey: 'QKEY_VAULTS',
+ * vaults: [vault1, vault2, vault3],
+ * raindexClient: client
+ * });📝 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.
| /** | |
| * Creates and initializes a new transaction for withdrawing funds from multiple vaults. | |
| * @param args - Configuration for the withdrawal transaction. | |
| * @param args.txHash - Hash of the transaction to track. | |
| * @param args.chainId - Chain ID where the transaction is being executed. | |
| * @param args.queryKey - The query key to invalidate, but for multiple vaults withdrawal it's QKEY_VAULTS | |
| * @param args.vaults - The list of RaindexVault instances from which funds are withdrawn. | |
| * @returns A new Transaction instance configured for withdrawal. | |
| * @example | |
| * const tx = await manager.createWithdrawTransaction({ | |
| * txHash: '0x123...', | |
| * chainId: 1, | |
| * queryKey: '0x789...', // Vault ID | |
| * entity: sgVaultInstance | |
| * }); | |
| */ | |
| /** | |
| * Creates and initializes a new transaction for withdrawing funds from multiple vaults. | |
| * @param args - Configuration for the withdrawal transaction. | |
| * @param args.txHash - Hash of the transaction to track. | |
| * @param args.chainId - Chain ID where the transaction is being executed. | |
| * @param args.queryKey - The query key to invalidate, but for multiple vaults withdrawal it's QKEY_VAULTS | |
| * @param args.vaults - The list of RaindexVault instances from which funds are withdrawn. | |
| * @returns A new Transaction instance configured for withdrawal. | |
| * @example | |
| * const tx = await manager.createMultipleVaultsWithdrawTransaction({ | |
| * txHash: '0x123...', | |
| * chainId: 1, | |
| * queryKey: 'QKEY_VAULTS', | |
| * vaults: [vault1, vault2, vault3], | |
| * raindexClient: client | |
| * }); | |
| */ |
🤖 Prompt for AI Agents
In packages/ui-components/src/lib/providers/transactions/TransactionManager.ts
around lines 174 to 189, the JSDoc example for createWithdrawTransaction is
outdated and references the old single vault withdrawal method and parameters.
Update the example to reflect the new method signature by using the correct
parameter names, including txHash, chainId, queryKey set to QKEY_VAULTS, and
vaults as an array of RaindexVault instances, ensuring the example matches the
current method usage.
|
Since there are too much architecture changes requested I've created a new PR: #2044 |
brusherru
changed the title
3 participants
Motivation
It closes #1963
Solution
From User perspective this PR adds:
e.g. you have 3 vaults there, and one of them is empty — then "Withdraw all" will withdraw only 2
at the same time if you have 3 vaults, and only one have a positive balance — there will be no "Withdraw all" button (but mb we'd better have it anyway?)
The same functionality also implemented in Tauri-app.
Also this PR introduces
generateMulticallCalldatafunction (js_api), which able to combine any calldata into multicallCall. So this PR also makes front-end able to decide which transactions it may want to put in a batch.Checks
By submitting this for review, I'm confirming I've done the following:
Screenshots
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores