Description

Fixes World Cup/sports game cards that could show only two outcomes for draw-capable moneyline games when one outcome had very low odds.

The shared market staleness filter removes outcomes priced at or below 5% or at or above 95%. That behavior is useful for multi-outcome non-game cards, but it breaks game cards that need the complete moneyline set. For example, Germany vs. Curacao has Germany, Draw, and Curacao outcomes, but Curacao can be priced below 5%. Once that outcome is filtered out, the card falls back to a binary path and the away-team button can open the No token for the favorite instead of the underdog moneyline.

This change skips stale-price outcome filtering and stale-price ranking penalties for game markets. Closed markets and ended games are still filtered out as before.

Changelog

CHANGELOG entry: Fixed a bug where sports game cards could hide low-probability outcomes and open the wrong prediction.

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/PRED-934?atlOrigin=eyJpIjoiZjVmNDJkY2I3NzBjNGQ4MjgwZWY5MjQ5ZjcyOTlkYWMiLCJwIjoiaiJ9

Manual testing steps

Feature: World Cup game card outcomes

  Scenario: user opens a draw-capable World Cup game card with a low-probability away team
    Given the World Cup feed includes a game with home, draw, and away moneyline outcomes
    And one of the moneyline outcomes is priced at or below 5%

    When user views the game card
    Then the card shows all available moneyline outcomes

    When user taps the away-team prediction button
    Then the buy sheet opens for the away-team outcome, not the favorite team's No token

Screenshots/Recordings

Before

After

Testing

• node .yarn/releases/yarn-4.14.1.cjs jest app/components/UI/Predict/utils/marketStaleness.test.ts

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.