CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

Medium severity

M1 — Claim-pending row is missing an accessibility role/label (tappable financial row)

In PredictTransactionsView.tsx, ClaimPendingPositionRow is a TouchableOpacity that navigates to market details, but it has no accessibilityRole="button" and no row-level accessibilityLabel. The only a11y annotation is on the icon (accessibilityLabel="claim pending icon"). Screen-reader users get the three child texts read out but no indication the row is actionable, and the navigation target isn't announced.

<TouchableOpacity
  onPress={handlePress}
  style={tw.style('flex-row items-start justify-between w-full p-2', containerStyle)}
  testID={getPredictPositionsHistoryListSelector.claimPendingRow(position.id)}
>

The existing PredictActivity rows are the comparison point — if they expose a button role, this new row should match. Recommendation: add accessibilityRole="button" and a meaningful accessibilityLabel (e.g. won title + market title), keeping the amount in SensitiveText.

M2 — Claim-pending history is not gated by the predictPortfolio flag

Only the balance-card Positions button is behind predictPortfolioEnabled. The new "Claim pending" history section is driven purely by the optional claimPendingPositions prop, and PredictPositionsView passes it unconditionally:

<PredictPositionsHistoryList
  claimPendingPositions={portfolio.actionableClaimablePositions}
  isPrivacyMode={Boolean(privacyMode)}
  isVisible={isHistoryTabActive}
/>

So any user who reaches PredictPositionsView > History (through any entry point, not just the flagged button) will see the new section — i.e. this part ships un-flagged, which differs from the PR's "behind a feature flag" framing. This may well be intentional (it's a separate, additive surface), but it's worth an explicit confirmation that shipping claim-pending history to all users reaching that view is desired, and that no other entry point exposes the Positions view prematurely. Recommendation: confirm intent; if it should be flagged, gate the prop on predictPortfolioEnabled as well.

Codecov Report

❌ Patch coverage is 89.74359% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.73%. Comparing base (02c85c2) to head (3580ded).
⚠️ Report is 41 commits behind head on main.

@@            Coverage Diff             @@
##             main   #30900      +/-   ##
==========================================
+ Coverage   82.70%   82.73%   +0.03%     
==========================================
  Files        5561     5576      +15     
  Lines      143081   143593     +512     
  Branches    33051    33204     +153     
==========================================
+ Hits       118336   118803     +467     
- Misses      16863    16877      +14     
- Partials     7882     7913      +31     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Medium severity

M1 — ClaimPendingPositionRow hardcodes "won" semantics while the prop is generically typed

Files: views/PredictTransactionsView/PredictTransactionsView.tsx

PredictTransactionsView accepts claimPendingPositions?: PredictPosition[] — a generic position array with no constraint on status. But the row unconditionally renders the "won" framing:

<Text variant={TextVariant.BodyMd} numberOfLines={1}>
  {strings('predict.transactions.prediction_won_title')}   // "Prediction won"
</Text>
...
accessibilityLabel = strings('predict.transactions.claim_pending_accessibility_label', {
  marketTitle: position.title,   // "Prediction won, {{marketTitle}}, opens market details"
});

This is only correct because the single current caller passes portfolio.actionableClaimablePositions, which usePredictPortfolio filters to status === WON && currentValue > 0. The component itself doesn't enforce that invariant, so any future caller passing non-won claimable positions (e.g. refunds) would be mislabeled both visually and for screen readers.

Recommendation: either narrow the prop type / document the WON-only contract explicitly, or derive the title from position.status rather than hardcoding it.

M2 — Fragile test mock relying on useSelector call-order parity

File: views/PredictPositionsView/PredictPositionsView.test.tsx

useSelector: jest.fn(() => {
  const value =
    mockUseSelectorCallIndex % 2 === 0 ? mockPrivacyMode : mockPredictPortfolioEnabled;
  mockUseSelectorCallIndex += 1;
  return value;
}),

This assumes the component always calls exactly two selectors, in a fixed order (selectPrivacyMode, then selectPredictPortfolioEnabledFlag), on every render. Adding, removing, or reordering a useSelector — or an extra render pass — will silently feed the wrong boolean to the wrong selector and produce confusing failures or false passes.

Recommendation: mock by selector identity instead of call index, e.g. useSelector.mockImplementation((sel) => sel === selectPrivacyMode ? mockPrivacyMode : mockPredictPortfolioEnabled). This is robust to render counts and call order.

High severity

H1 — "Claim pending" section is fed the unfiltered claimablePositions, so non-actionable / lost / $0 positions appear under a header that implies money to claim

Files: views/PredictPositionsView/PredictPositionsView.tsx, views/PredictTransactionsView/PredictTransactionsView.tsx, hooks/usePredictPortfolio.ts

PredictPositionsView passes the raw claimable list to the history:

<PredictPositionsHistoryList
  claimPendingPositions={
    predictPortfolioEnabled ? portfolio.claimablePositions : undefined
  }
  isPrivacyMode={Boolean(privacyMode)}
  isVisible={isHistoryTabActive}
/>

portfolio.claimablePositions is just usePredictPositions({ claimable: true }) — every position where p.claimable === true, with no status / value filtering:

// usePredictPositions.ts — buildSelect
if (claimable === true) {
  result = result.filter((p) => p.claimable);
}

The hook deliberately exposes a separate, narrower list for exactly this kind of "actionable winnings" surface:

// usePredictPortfolio.ts
const actionableClaimablePositions = useMemo(
  () =>
    claimablePositions.filter(
      (position) =>
        position.status === PredictPositionStatus.WON &&
        position.currentValue > 0,
    ),
  [claimablePositions],
);

actionableClaimablePositions is what drives claimableAmount, claimablePositionCount, hasClaimableWinnings, and the positions badge count. Feeding the unfiltered list into a section titled "Claim pending" means:

• LOST positions (and any currentValue === 0 entry) render in the "Claim pending" section. The row code even has explicit branches for this — getClaimPendingPositionTitle returns "Prediction lost" / "Prediction resolved", and the amount renders as $0.00. A user sees an item titled "Prediction lost — $0.00" sitting under "Claim pending", where there is nothing to claim.
• It is inconsistent with the rest of the portfolio UI (badge/count/amount all use actionableClaimablePositions), so the section can disagree with the claimable count/amount shown elsewhere.
• It contradicts the PR description, which frames this as surfacing "claimable winnings" / "claimable positions."

The PR's own test (passes won and lost claimable positions ..., expecting count 2) and the labels lost claim pending positions from position status test show this is the current intended behavior of the code — but it looks like a regression from the previously reviewed head (which passed actionableClaimablePositions).

Recommendation: pass portfolio.actionableClaimablePositions (matching the badge/amount logic), or, if showing all resolved positions is genuinely intended, rename the section away from "Claim pending" and confirm the product decision. Either way, the section header and its contents must agree.

Medium severity

M1 — claimPendingPositions prop is generically typed with no enforced contract

File: views/PredictTransactionsView/PredictTransactionsView.tsx

PredictTransactionsView accepts claimPendingPositions?: PredictPosition[] with no constraint on status or currentValue. The component now derives the row title from position.status (good — fixes the earlier "hardcoded won" concern), but it still has no guard that the supplied positions are actually claimable/actionable. Combined with H1, this is what lets lost/$0 rows flow into a "Claim pending" UI. Even after H1 is fixed at the call site, the component itself does not document or defend the invariant, so the next caller can reintroduce the same problem.

Recommendation: document the expected contract (actionable, claimable winnings) in JSDoc, and/or defensively filter inside the component, and/or narrow the type.

M2 — Pull-to-refresh does not refresh the "Claim pending" section

File: views/PredictTransactionsView/PredictTransactionsView.tsx

onRefresh / handleRetry only call the activity refetch(). claimPendingPositions are owned by the parent (usePredictPortfolio / usePredictPositions) and are not re-fetched here, so after a manual pull-to-refresh the "Claim pending" section can be stale relative to the freshly-refetched activity list below it (e.g., a position the user just claimed still shows as pending until the parent query refreshes on its own).

Recommendation: thread a refresh callback from the parent (or call the portfolio refetch) so both data sources refresh together.

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokePredictions, SmokeWalletPlatform
• Selected Performance tags: @PerformancePredict
• Risk Level: medium
• AI Confidence: 88%

View GitHub Actions results