-
-
Notifications
You must be signed in to change notification settings - Fork 270
feat(transaction-controller): feature flags for history limits #7648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…action history limit Add a new historyLimit property to FeatureFlag.Transactions that allows configuring the maximum number of entries in the submit history via remote feature flags. The default value remains 100 if not provided. - Add historyLimit to TransactionControllerFeatureFlags type - Create getHistoryLimit function to retrieve the feature flag value - Update TransactionController to use getHistoryLimit instead of static constant - Add unit tests for getHistoryLimit function Co-authored-by: matthew.walsh <matthew.walsh@consensys.net>
…tionController tests Update TransactionController.test.ts to properly mock the getHistoryLimit function from the feature-flags module. This is necessary because the feature-flags module is fully mocked in the test file, so the new getHistoryLimit function needs to be imported and configured to return the default value of 100. Co-authored-by: matthew.walsh <matthew.walsh@consensys.net>
|
Cursor Agent can help with this pull request. Just |
…ature flag Co-authored-by: matthew.walsh <matthew.walsh@consensys.net>
…nd transaction history limits - Rename historyLimit to submitHistoryLimit for the submit history (default: 100) - Add transactionHistoryLimit feature flag for transaction state limit (default: 40) - Update TransactionController to use feature flags with fallback to constructor options - Update tests to mock both feature flag functions Co-authored-by: matthew.walsh <matthew.walsh@consensys.net>
…onstructor option - Mark transactionHistoryLimit constructor option as deprecated with JSDoc - Remove internal usage of the constructor option - Feature flag is now the sole source of truth for transaction history limit - Update changelog to document the deprecation Co-authored-by: matthew.walsh <matthew.walsh@consensys.net>
- Move feature-flags import to correct alphabetical position - Fix formatting of getTransactionHistoryLimitMock declaration Co-authored-by: matthew.walsh <matthew.walsh@consensys.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
jpuri
approved these changes
Jan 16, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
What is the current state of things and why does it need to change?
The
TransactionControllercurrently uses:SUBMIT_HISTORY_LIMITconstant (100) to manage the maximum number of entries in the submit historytransactionHistoryLimitconstructor option (default: 40) to manage the maximum number of transactions stored in stateThese limits need to be configurable via remote feature flags to allow for dynamic adjustments without code changes.
What is the solution your changes offer and how does it work?
This PR introduces two feature flags under
FeatureFlag.Transactions:submitHistoryLimit- Configures the maximum number of entries in the submit history#updateSubmitHistorymethodtransactionHistoryLimit- Configures the maximum number of transactions stored in state#trimTransactionsForStatemethodNew utility functions
getSubmitHistoryLimitandgetTransactionHistoryLimitretrieve these values from theRemoteFeatureFlagController.Are there any changes whose purpose might not obvious to those unfamiliar with the domain?
The comparison in
#updateSubmitHistorywas changed from===to>=. This ensures that if thesubmitHistoryLimitis dynamically reduced, the history will still be trimmed correctly, rather than only when it exactly matches the limit.The
transactionHistoryLimitconstructor option has been marked as deprecated. Consumers should migrate to using the feature flag viaRemoteFeatureFlagControllerinstead.References
Checklist
Note
Introduces remote-configurable history limits and wires them into
TransactionController.getSubmitHistoryLimit(default 100) andgetTransactionHistoryLimit(default 40) inutils/feature-flags, exposed underFeatureFlag.TransactionsTransactionControllerto: trim state in#trimTransactionsForStateand cap submit history in#updateSubmitHistory(comparison changed to>=); removeSUBMIT_HISTORY_LIMITTransactionControllerOptions.transactionHistoryLimitin favor of the feature flagTransactionController.test.tsand addfeature-flags.test.ts; updateCHANGELOG.mdWritten by Cursor Bugbot for commit 896fe82. This will update automatically on new commits. Configure here.