High-priority issues

H1. Chainlink-candles history endpoint silently returns empty for non-recent / expired markets

const { CHAINLINK_CANDLES_ENDPOINT } = getPolymarketEndpoints();
const { interval, limit } =
  CHAINLINK_CANDLE_CONFIG_BY_VARIANT[variant] ??
  DEFAULT_CHAINLINK_CANDLE_CONFIG;
const searchParams = new URLSearchParams({
  symbol: normalizedSymbol,
  interval,
  limit: String(limit),
});

// ...

return data.candles
  .filter((entry): entry is { time: number; close: number } => ... )
  .filter((entry) =>
    isWithinWindow({
      timestamp: entry.time,
      startSeconds,
      endSeconds,
    }),
  )
  .map((entry) => ({
    timestamp: entry.time,
    value: entry.close,
  }));

The previous price-history endpoint took eventStartTime and endDate as server-side query parameters, so the server returned data for the exact window. The new endpoint only accepts symbol, interval, limit and always returns the latest limit candles, then we client-side filter to [startSeconds, endSeconds]. This is fine while the user looks at a live market, but it breaks for any historical look-up:

• A user opens PredictCryptoUpDownDetails and taps a past time slot in the TimeSlotPicker for a 5-min BTC market that ended 1 hour ago.
• The hook requests { symbol: 'BTC', interval: '1m', limit: 15 } → server returns the last 15 minutes from now, e.g. timestamps in [now-15m, now].
• Client filters by endSeconds = market.endDate (1 hour ago) → every candle fails the <= endSeconds check → returns [].
• The details chart shows nothing for that time slot.

For longer recurrences this is worse:

• daily returns 30 × 1h candles = the last 30 hours only. Tap a daily market from yesterday → no data, even though "yesterday" is well within 30h.
• 4h returns 60 × 5m candles = last 5 hours. Tap a 4h market from 6 hours ago → empty.

The "past time slot" path is exactly what TimeSlotPicker is built for in PredictCryptoUpDownDetails. The PR adds the picker integration but does not add coverage for this regression. The unit tests on the provider ('gets crypto price history from Chainlink candle closes', 'uses supported Chainlink candle intervals…') only assert that the URL is built correctly — they don't assert that requesting a historical window actually returns the candles for that window.

Suggested fix (in priority order):

1. Have the server-side endpoint accept startTime/endTime (or from/to) and return the candles for that window, the same way the previous endpoint did. This is the only fix that scales beyond the recurrence-sized lookback table.
2. Failing that, dynamically compute limit from endDate - eventStartTime so the limit covers the requested window (e.g. Math.ceil((endSeconds - startSeconds) / intervalSeconds) + safetyMargin).
3. At minimum, log a warning when the response is non-empty but all candles fail the window filter — currently the UI silently shows an empty chart.

A direct regression test for this path:

it('returns empty when the requested window is older than limit * interval', async () => {
  global.fetch = jest.fn().mockResolvedValue({
    ok: true,
    json: () => Promise.resolve({
      candles: Array.from({ length: 15 }, (_, i) => ({
        time: 10_000 + i * 60,
        close: 100 + i,
      })),
    }),
  });

  const result = await createProvider().getCryptoPriceHistory({
    symbol: 'BTC',
    eventStartTime: '1000',
    endDate: '1300',
    variant: 'fiveminute',
  });

  expect(result).toEqual([]); // currently passes silently — this is the regression
});

This isn't a hypothetical: it's exercised every time a user taps a non-live time slot in the new details screen the PR plugs the card into.

Medium-priority issues

M1. OutcomeButtons opens the buy sheet on resolved/closed markets at rollover boundaries

const { getPrice } = useLiveMarketPrices(tokenIds, {
  enabled: marketStatus === PredictMarketStatus.OPEN,
});
const upPrice = getLivePrice(upToken, getPrice);
const downPrice = getLivePrice(downToken, getPrice);

return (
  <Box flexDirection={BoxFlexDirection.Row} twClassName="...">
    <ButtonBase
      testID={PredictCryptoUpDownMarketCardSelectorsIDs.UP_BUTTON}
      onPress={() => onBuyPress(upToken)}
      twClassName="h-10 flex-1 rounded-lg bg-success-muted"
      disabled={!upToken}
    >
      ...
    </ButtonBase>
    <ButtonBase
      testID={PredictCryptoUpDownMarketCardSelectorsIDs.DOWN_BUTTON}
      onPress={() => onBuyPress(downToken)}
      twClassName="h-10 flex-1 rounded-lg bg-error-muted"
      disabled={!downToken}
    >
      ...
    </ButtonBase>
  </Box>
);

disabled is only !upToken/!downToken. The live-prices subscription correctly gates on marketStatus === OPEN, but the buttons themselves don't. Combined with resolvePredictSeriesMarket falling back to findNearestMarket when findLiveMarket returns undefined:

export const resolvePredictSeriesMarket = (
  sourceMarket: PredictMarketWithSeries,
  seriesMarkets?: PredictMarket[],
): PredictMarketWithSeries => {
  if (!seriesMarkets?.length) {
    return sourceMarket;
  }

  return attachSeriesToMarket(
    findLiveMarket(seriesMarkets) ??
      findNearestMarket(seriesMarkets) ??
      sourceMarket,
    sourceMarket.series,
  );
};

findNearestMarket happily returns a market whose endDate is in the past (its check is Math.abs(... - now), not "> now"). At exactly the rollover boundary, before the next usePredictSeries window refetch finishes, selectedMarket is the just-expired market. The user taps Up → handleBuyPress runs executeGuardedAction(... openBuySheet({ market: selectedMarket, outcome, outcomeToken, ... })). openBuySheet opens the betslip for a closed outcome; downstream rejection emits an order-failure toast.

Two recommended changes:

1. Gate the buttons:

   disabled={!upToken || marketStatus !== PredictMarketStatus.OPEN}

   and likewise for Down. This also fixes the visual cue (right now the buttons look identical regardless of market status).
2. Add a guard in handleBuyPress that early-returns if selectedMarket.status !== PredictMarketStatus.OPEN. Defense in depth — the parent feed could pass a non-live market via market prop.

A unit test covering this path is missing — the existing "renders missing outcome data without opening a buy sheet" test (lines 449–466) only covers the outcomes: [] edge case, not status.

M2. Per-card 1-minute history refetch fires for every feed card

const chartHistoryEndMs = useSharedBucketedNowMs(
  CHART_HISTORY_WINDOW_BUCKET_MS,
);
const chartHistoryWindow = useMemo(
  () => ({
    startDate: new Date(
      chartHistoryEndMs - chartRequestDurationMs,
    ).toISOString(),
  }),
  [chartHistoryEndMs, chartRequestDurationMs],
);

CHART_HISTORY_WINDOW_BUCKET_MS = 60 * 1000. Every 60 seconds the startDate in chartHistoryWindow ticks forward, the react-query key in useCryptoUpDownChartData changes, and the card re-fetches its history. With:

staleTime: shouldStreamLive ? 1000 : Infinity,
refetchOnMount: shouldStreamLive || !liveUpdatesEnabled ? 'always' : false,

staleTime: Infinity doesn't help because each minute creates a new query key. On a feed showing N crypto up/down cards, that's N requests/minute sustained, plus an extra refetch on every mount. For a typical 5-card feed view on cellular this is borderline.

Two options:

1. Keep chartHistoryWindow stable across the recurrence's display duration (e.g. bucket at chartDisplayDurationMs / 12 instead of fixed 60s, so a daily card refetches every 2 hours and a 5m card every ~25s).
2. Anchor startDate to a stable epoch (getCurrentSeriesWindowMs) and let staleTime: Infinity actually cache. The chart already merges historical+live points; older history sliding forward by 60s is invisible to the user for a 24h-wide daily chart.

M3. useCurrentPredictMarketFromSeries polls at 1Hz when the window changes at durationMs granularity

useEffect(() => {
  if (!enabled || !resolvedSeriesId) {
    return undefined;
  }

  const interval = setInterval(() => {
    const nextWindowMs = getCurrentSeriesWindowMs(durationMs);
    setWindowMs((currentWindowMs) =>
      currentWindowMs === nextWindowMs ? currentWindowMs : nextWindowMs,
    );
  }, 1000);

  return () => clearInterval(interval);
}, [durationMs, enabled, resolvedSeriesId]);

For a 5m market, windowMs only changes once every 5 minutes, but this interval fires 300 times per change — and each tick runs getCurrentSeriesWindowMs and a setState call (gated to no-op). For a daily market, that's 86,400 ticks per useful change.

PredictCryptoUpDownDetails solves this correctly: schedule a setTimeout for the next boundary and re-schedule on fire. Apply the same pattern here:

useEffect(() => {
  if (!enabled || !resolvedSeriesId) return undefined;
  let timeout: ReturnType<typeof setTimeout>;
  const schedule = () => {
    const nowMs = Date.now();
    const delay = durationMs - (nowMs % durationMs);
    timeout = setTimeout(() => {
      setWindowMs(getCurrentSeriesWindowMs(durationMs));
      schedule();
    }, delay);
  };
  schedule();
  return () => clearTimeout(timeout);
}, [durationMs, enabled, resolvedSeriesId]);

This eliminates 99% of the wakeups for the hook, which is also called by PredictMarketDetails on every render (via the new deep-link resolution path).

M4. getCurrentWindowMs is duplicated in PredictCryptoUpDownDetails.tsx

const getCurrentWindowMs = (durationMs: number) => {
  const currentTimeMs = Date.now();
  if (!Number.isFinite(currentTimeMs) || durationMs <= 0) {
    return 0;
  }

  return Math.floor(currentTimeMs / durationMs) * durationMs;
};

vs.

export const getCurrentSeriesWindowMs = (
  durationMs: number,
  nowMs = Date.now(),
): number => {
  if (!Number.isFinite(nowMs) || durationMs <= 0) {
    return 0;
  }

  return Math.floor(nowMs / durationMs) * durationMs;
};

The PR extracted getCurrentSeriesWindowMs to the shared utils/series.ts (and adopted it in the card) but left this local copy in PredictCryptoUpDownDetails.tsx. Two near-identical implementations of the same primitive will drift. Replace the local function with the shared one (and import findLiveMarket from utils/series directly while you're there — it's already a re-export at TimeSlotPicker.utils.ts).

M5. getVariant silently maps unknown recurrences to 'hourly'

export function getVariant(recurrence: string): string {
  return RECURRENCE_TO_VARIANT[recurrence] ?? 'hourly';
}

Combined with the new endpoint:

const CHAINLINK_CANDLE_CONFIG_BY_VARIANT: Record<
  string,
  { interval: ChainlinkCandleInterval; limit: ChainlinkCandleLimit }
> = {
  fiveminute: { interval: '1m', limit: 15 },
  fifteen: { interval: '1m', limit: 30 },
  hourly: { interval: '1m', limit: 60 },
  fourhour: { interval: '5m', limit: 60 },
  daily: { interval: '1h', limit: 30 },
};

A future crypto recurrence (e.g., '30m', which is already a valid key in series.ts/RECURRENCE_MAP) will return variant = 'hourly' from getVariant, then { interval: '1m', limit: 60 } = 1h of data on a 30-min event — half too much, half stale. For a weekly recurrence (also in RECURRENCE_MAP) it's catastrophic: 1h of data on a 7-day event window.

Two mitigations:

1. Make getVariant return undefined for unknown recurrences and have callers handle "not chartable" instead of pretending the data exists.
2. Add a DevLogger.log('Unknown variant, falling back to hourly', { recurrence }) so the fallback is visible during QA.

The same drift risk exists between series.ts/RECURRENCE_MAP and cryptoUpDown.ts/RECURRENCE_TO_DURATION_SECS — they overlap on 5m, 15m, 1h, 4h, daily but diverge on 30m, weekly, hourly. Either consolidate to a single map or make cryptoUpDown.ts re-export from series.ts.

M6. Module-level state in PredictCryptoUpDownMarketCard has no test-reset hook

let sparklineGradientIdCounter = 0;
const CLOCK_UPDATE_OFFSET_MS = 50;
const clockListeners = new Set<() => void>();
let clockNowMs = Date.now();
let clockTimeout: ReturnType<typeof setTimeout> | undefined;

Three pieces of module-level state:

• sparklineGradientIdCounter — monotonically increasing; never decremented. Should be React 18's useId() so each <Sparkline> instance has a stable, render-deterministic id (helps SSR/concurrent rendering too, and avoids test bleed).
• clockListeners + clockNowMs + clockTimeout — shared module-level clock. If a test (or its teardown) leaves a listener registered, the next test in the same file sees the leftover and may observe phantom updates. Same hazard PR fix(predict): prevent buy/sell sheet from being cropped in HomepageDiscoveryTabs #30219 had with _providerSheetModeCount.

Recommended:

1. Replace sparklineGradientIdCounter with useId.
2. Export a __resetCardClockForTest() or rename the module-state into a singleton class so tests can new ClockClient() per case.
3. The existing test calls jest.clearAllMocks() in beforeEach but does not reset the clock state. The current tests pass because each test reaches steady state quickly, but this is a slow-to-find footgun.

M7. PredictMarketDetails deep-link path with series but no series.id/seriesId shows a perpetual skeleton

const shouldResolveMarketFromSeries =
  !marketId && Boolean(series?.id ?? seriesId);
const {
  market: currentSeriesMarket,
  marketId: currentSeriesMarketId,
  isLoading: isCurrentSeriesMarketLoading,
  isFetching: isCurrentSeriesMarketFetching,
  refetch: refetchCurrentSeriesMarket,
} = useCurrentPredictMarketFromSeries({
  series,
  seriesId,
  seriesRecurrence,
  enabled: shouldResolveMarketFromSeries,
});
const resolvedMarketId = marketId ?? currentSeriesMarketId;

If a deep link arrives with series: { id: '', slug: '', title: '', recurrence: '5m' } (a malformed payload, e.g. from a stale share link), then series.id is falsy, seriesId is undefined, shouldResolveMarketFromSeries=false, resolvedMarketId=undefined, useCurrentPredictMarketFromSeries is disabled, usePredictMarket({ id: '', enabled: false }) is also disabled, and isResolvedMarketLoading = isMarketLoading || isResolvingMarketFromSeries. Both flags are false, so isResolvedMarketLoading=false, the skeleton hides, market=null, and the user sees an empty white screen with no error path or "not found" message.

This is an edge case but trivially reachable via stale share URLs. Add a minimal "market unavailable" branch when !resolvedMarketId && !isResolvedMarketLoading.

🔍 Smart E2E Test Selection

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

View GitHub Actions results

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud