Remove SPK Network support#3319
Conversation
|
Warning Review limit reached
Next review available in: 19 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesSDK dependency update
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 451e5dbede
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| isEngine: (asset as SelectableAsset).isEngine ?? base.layer === 'engine', | ||
| isSpk: (asset as SelectableAsset).isSpk ?? base.layer === 'spk', | ||
| isChain: (asset as SelectableAsset).isChain ?? base.layer === 'chain', |
There was a problem hiding this comment.
Filter SDK SPK assets out of the picker
Because @ecency/sdk is still pinned to the SPK-enabled 2.3.28 release and useAssetsQuery({ onlyEnabled: false }) does not filter data.wallets, SPK/LARYNX items with layer: 'spk' can still arrive in assetsQuery.selectedableData. After this change mapAssetLayer no longer marks them as SPK or excludes them, so they remain selectable as generic assets; applying the picker writes them into Redux selected assets, where the now-removed SPK transfer/action paths only fail. Please drop layer === 'spk' assets at this boundary until the SDK is bumped or filtered upstream.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Resolved by c2e8709: @ecency/sdk is bumped to ^2.3.32 in this PR. That release's getPortfolioQueryOptions filters out layer: 'spk' rows client-side, and the portfolio endpoint no longer returns SPK entries, so they can't reach selectedableData.
Greptile SummaryThis PR removes all SPK Network token-layer support (SPK / LARYNX / LP) from the mobile app and adds the data-hygiene machinery needed to keep existing users in a clean state. It is a companion to the already-merged vision-next removal.
Confidence Score: 5/5Safe to merge — the removal is consistent end-to-end, the redux migration is guarded and tested, and the latent TokenType import bug is fixed. All SPK call sites are removed cleanly, the persist-version bump triggers v19 on first launch, engine tokens sharing SPK-colliding symbols are correctly exempted, and the fix that corrects the broken TokenType import from assetsSelect.tsx to walletReducer.ts resolves a real runtime breakage in the legacy token migration path. Tests cover the new migration and the updated object-to-array conversion path. src/utils/migrationHelpers.ts — the array-format branch of migrateSelectedTokens does not filter SPK entries, so a user whose posting_json_metadata was already in array form will retain stale SPK tokens there until their next explicit profile save (display guards prevent them from appearing, but the metadata stays dirty in the interim). Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App launch after upgrade] --> B{persist version < 19?}
B -- yes --> C[Migration v19 runs]
B -- no --> G[Normal startup]
C --> D["Filter wallet.selectedAssets:\n!isSpk AND (isEngine OR symbol not in SPK/LARYNX/LP)"]
D --> E[SPK/LARYNX/LP assets purged]
D --> F[Engine LP tokens and non-SPK assets kept]
E --> G
G --> H[walletScreen loads profile tokens]
H --> I{"token.type === 'SPK'?"}
I -- yes --> J[Token dropped from display]
I -- no --> K[Token shown in wallet]
G --> L[assetsSelect loads profile tokens]
L --> M{"String(type) === 'SPK'?"}
M -- yes --> N[Token excluded from selection list]
M -- no --> O[Token shown for selection]
O --> P[User saves - SPK entries never written back]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[App launch after upgrade] --> B{persist version < 19?}
B -- yes --> C[Migration v19 runs]
B -- no --> G[Normal startup]
C --> D["Filter wallet.selectedAssets:\n!isSpk AND (isEngine OR symbol not in SPK/LARYNX/LP)"]
D --> E[SPK/LARYNX/LP assets purged]
D --> F[Engine LP tokens and non-SPK assets kept]
E --> G
G --> H[walletScreen loads profile tokens]
H --> I{"token.type === 'SPK'?"}
I -- yes --> J[Token dropped from display]
I -- no --> K[Token shown in wallet]
G --> L[assetsSelect loads profile tokens]
L --> M{"String(type) === 'SPK'?"}
M -- yes --> N[Token excluded from selection list]
M -- no --> O[Token shown for selection]
O --> P[User saves - SPK entries never written back]
Reviews (3): Last reviewed commit: "exempt engine tokens from v19 SPK symbol..." | Re-trigger Greptile |
Removes the SPK Network token layer (SPK / LARYNX / LP) from the app, companion to the vision-next removal (ecency/vision-next#1063, merged).
Removed
providers/hive-spk(SPK node client, wallet/markets fetchers, custom_json builders)useTransferSpkMutation,useTransferLarynxMutation,usePowerLarynxMutation,useLockLarynxMutation)transferContainer,transferScreen,useTransferMutations,transactionOpsBuilderASSET_IDS.SPK/LARYNX/LARYNX_POWER,TokenLayers.SPK,TokenType.SPK,isSpkplumbing across wallet/assets screens and asset icon badgehive_spk.pngassetData hygiene
wallet.selectedAssets(persist version 18 → 19)walletScreen,assetsSelect) now filter staletype: 'SPK'entries from on-chainposting_json_metadata, so old profiles self-healmigrationHelpers:TokenType/ProfileTokenwere imported from a module that doesn't export them, which broke the legacy token-format migration at runtimeDependencies
@ecency/sdkbumped ^2.3.28 → ^2.3.32: SPK-free SDK plus the latest REST-node configuration and rate-limit backoff improvementsUntouched
allowSpkPublishinggate (video publishing state, unrelated to the token layer)jest green (469 tests) and lint clean on the bumped SDK.
Summary by CodeRabbit