ZhuLinsen/daily_stock_analysis · warning · ValueError

Phase-filtered summary matches too many rows; narrow the ana

Error message

Phase-filtered summary matches too many rows; narrow the analysis date range or stock code.

What it means

Even when the pre-count passes, the phase-filtered path fetches rows with context (limit MAX_DYNAMIC_SUMMARY_ROWS+1); if more than the cap come back, the in-memory phase bucketing would be over budget and this ValueError is raised (HTTP 400). It is the second-stage guard after the count check at line 596/600.

Source

Thrown at src/services/backtest_service.py:611

            )
            if count > self.MAX_DYNAMIC_SUMMARY_ROWS:
                if phase_bucket is not None:
                    raise ValueError(
                        "Phase-filtered summary candidate set matches too many rows; "
                        "narrow the analysis date range, stock code, or evaluation window."
                    )
                raise ValueError("Date-filtered summary matches too many rows; narrow the analysis date range or stock code.")
            if phase_bucket is not None:
                rows_with_context = self.repo.list_results_with_context(
                    code=code,
                    eval_window_days=ew,
                    engine_version=engine_version,
                    analysis_date_from=analysis_date_from,
                    analysis_date_to=analysis_date_to,
                    limit=self.MAX_DYNAMIC_SUMMARY_ROWS + 1,
                )
                if len(rows_with_context) > self.MAX_DYNAMIC_SUMMARY_ROWS:
                    raise ValueError(
                        "Phase-filtered summary matches too many rows; narrow the analysis date range or stock code."
                    )
                filtered_pairs = [
                    (row, snapshot)
                    for row, snapshot in rows_with_context
                    if self._phase_bucket_from_snapshot(snapshot) == phase_bucket
                ]
                phase_counts = self._phase_counts_from_contexts([snapshot for _, snapshot in filtered_pairs])
                filtered_rows = [row for row, _ in filtered_pairs]
                return self._build_dynamic_summary(
                    rows=filtered_rows,
                    scope=scope,
                    code=lookup_code,
                    eval_window_days=int(eval_window_days) if eval_window_days is not None else None,
                    engine_version=engine_version,
                    max_rows=self.MAX_DYNAMIC_SUMMARY_ROWS,
                    phase_breakdown=phase_counts["phase_breakdown"],
                    raw_phase_counts=phase_counts["raw_phase_counts"],

View on GitHub (pinned to 5159bd72e8)

Solutions

Retry with a narrower analysis_date range or a specific code — the same remedy the message suggests.
If it recurs only during active backtest runs, query the summary after the run finishes to avoid the count/fetch race.
If persistent at stable data volume, verify count_results and list_results_with_context apply identical filters in the repository layer.

Example fix

# before
summary = service.get_backtest_summary(analysis_phase="intraday")

# after
summary = service.get_backtest_summary(
    analysis_phase="intraday",
    analysis_date_from="2026-08-01",
    analysis_date_to="2026-08-14",
)

Defensive patterns

Strategy: retry

Validate before calling

rows = service.repo.list_results_with_context(code=code, eval_window_days=eval_window_days, engine_version=engine_version, analysis_date_from=dfrom, analysis_date_to=dto, limit=service.MAX_DYNAMIC_SUMMARY_ROWS + 1)
if len(rows) > service.MAX_DYNAMIC_SUMMARY_ROWS:
    raise_for_ui("narrow filters")  # before calling get_backtest_summary

Try / catch

for attempt in range(2):
    try:
        return service.get_backtest_summary(analysis_phase=phase, analysis_date_from=dfrom, analysis_date_to=dto)
    except ValueError as exc:
        if "too many rows" not in str(exc) or attempt == 1:
            raise
        dfrom = tighten(dfrom, dto)  # boundary/race case: shrink and retry once

Prevention

Avoid querying summaries while a backtest run is writing rows (race between count and fetch).
Leave headroom under the cap rather than sitting exactly at the boundary.
Treat repeated boundary failures as a signal to prune data or tighten default filters.

When it happens

Trigger: get_backtest_summary(analysis_phase=...) where count_results returned <= MAX_DYNAMIC_SUMMARY_ROWS but list_results_with_context returned MAX_DYNAMIC_SUMMARY_ROWS+1 rows — e.g. concurrent writers added rows between count and fetch, or the two repo queries disagree on filters.

Common situations: A backtest run writing new rows while the summary endpoint is queried; boundary datasets sitting exactly at the cap; filter drift between count_results and list_results_with_context.

Related errors

AI-assisted analysis of ZhuLinsen/daily_stock_analysis@5159bd72e8 (2026-08-15). Data as JSON: /api/errors/eb09ac426b67e4cb. Report an issue: GitHub.