build(deps): upgrade wallet connect dependencies #5129
Conversation
1 build increased size
Celo (test) 1.81.0 (146)
|
| Item | Install Size Change |
|---|---|
| 🗑 celo | ⬇️ -15.5 MB |
| 📝 valora | ⬆️ 1.6 MB |
| 📝 Lottie | ⬆️ 785.9 kB |
| 📝 Code Signature | ⬆️ 662.7 kB |
| 📝 Strings.CFStrings | ⬆️ 650.7 kB |
View Treemap
🛸 Powered by Emerge Tools
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5129 +/- ##
==========================================
- Coverage 85.70% 85.70% -0.01%
==========================================
Files 729 730 +1
Lines 29854 29863 +9
Branches 5160 5156 -4
==========================================
+ Hits 25587 25594 +7
- Misses 4032 4034 +2
Partials 235 235
... and 8 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
|
Not sure why Codecov is complaining. The new type is tested in |
package.json
Outdated
| "@walletconnect/sign-client": "2.10.0", | ||
| "@walletconnect/types": "2.10.0", | ||
| "@walletconnect/sign-client": "2.11.3", | ||
| "@walletconnect/types": "2.11.3", |
There was a problem hiding this comment.
do we still need to keep these as exact versions instead of range versions?
| @@ -87,7 +87,7 @@ export const reducer = ( | |||
| .includes(pendingAction.topic) | |||
| ), | |||
| pendingSessions: state.pendingSessions.filter( | |||
| (pendingSession) => pendingSession.params.expiry > action.dateInSeconds | |||
| (pendingSession) => pendingSession.params.expiryTimestamp > action.dateInSeconds | |||
There was a problem hiding this comment.
@MuckT codecov is complaining about this line not having tests. Maybe worth adding one given this is a more complex reducer?
Also, would this need a migration? could there be a persisted pendingSession with expiry instead of expiryTimestamp?
There was a problem hiding this comment.
I thought pending sessions where pretty ephemeral, but at second glance we might need migration otherwise the old ones may never expire. I wonder if it might be safer and easier to clear the pendingSessions entirely instead of a migration the pendingSessions params.expiry to params.expiryTimestamp.
There was a problem hiding this comment.
If the only change in schema is expiry to expiryTimestamp, then an inplace migration is fine, but if other fields are also changing, clearing seems good. Also, just for my understanding, how do pending sessions work when the app restarts?
| @@ -87,7 +87,7 @@ export const reducer = ( | |||
| .includes(pendingAction.topic) | |||
| ), | |||
| pendingSessions: state.pendingSessions.filter( | |||
| (pendingSession) => pendingSession.params.expiry > action.dateInSeconds | |||
| (pendingSession) => pendingSession.params.expiryTimestamp > action.dateInSeconds | |||
There was a problem hiding this comment.
If the only change in schema is expiry to expiryTimestamp, then an inplace migration is fine, but if other fields are also changing, clearing seems good. Also, just for my understanding, how do pending sessions work when the app restarts?
|
@satish-ravi pending sessions are added whenever there is a SESSION_PROPOSAL action and are removed whenever this proposal is accepted or denied. In the case of an application close while there are pending session it should be served when the application is reopened. |
### Description Upgrades Wallet Connect dependencies to the latest versions: originally pinned in valora-inc#4406. ### Test plan - Tested locally on iOS and Android - Connect - Verify - Sign Transaction ### Related issues - Related: ACT-962 ### Backwards compatibility Yes ### Network scalability N/A
Description
Upgrades Wallet Connect dependencies to the latest versions: originally pinned in #4406.
Test plan
Related issues
Backwards compatibility
Yes
Network scalability
N/A