ZhuLinsen/daily_stock_analysis · error · DataFetchError

TickFlow daily K-line response may be truncated by count: sy

Error message

TickFlow daily K-line response may be truncated by count: symbol={symbol} start={start_date} end={end_date} rows={len(frame)} count={count}

What it means

DataFetchError raised by TickFlowFetcher._prepare_daily_frame when the response's row count equals the requested count cap — the response may have been truncated by the 'count' parameter, so continuing would silently produce incomplete history. The fetcher deliberately rejects the response (integrity guard) after logging a detailed warning.

Source

Thrown at data_provider/tickflow_fetcher.py:495

            end_date=end_date,
            count=count,
            returned_rows=len(frame),
        ):
            first_date = valid_dates.min().strftime("%Y-%m-%d")
            last_date = valid_dates.max().strftime("%Y-%m-%d")
            logger.warning(
                "[TickFlowFetcher] reject incomplete daily K-line response: symbol=%s context=%s "
                "start=%s end=%s first=%s last=%s rows=%d count=%d reason=count_cap",
                symbol,
                context,
                start_date,
                end_date,
                first_date,
                last_date,
                len(frame),
                count,
            )
            raise DataFetchError(
                "TickFlow daily K-line response may be truncated by count: "
                f"symbol={symbol} start={start_date} end={end_date} rows={len(frame)} count={count}"
            )

        start = pd.Timestamp(start_date).normalize()
        end = pd.Timestamp(end_date).normalize()
        in_range = dates.notna() & (dates >= start) & (dates <= end)
        if not in_range.any():
            return pd.DataFrame(columns=frame.columns)
        return frame.loc[in_range].reset_index(drop=True)

    @classmethod
    def _is_daily_frame_truncated(
        cls,
        *,
        dates: pd.Series,
        start_date: str,
        end_date: str,

View on GitHub (pinned to 5159bd72e8)

Solutions

Split the request into smaller date chunks so each chunk's trading-day count stays below the cap.
Raise the count cap in _daily_kline_count / the request if the API allows larger pages.
If chunking is already correct and this persists, compare rows against an independent calendar to detect API-side truncation and report it.

Example fix

# before
# single request over 5 years -> rows == count -> DataFetchError
rows = tickflow_fetcher.get_stock_history_with_limit("600519", start="2020-01-01", end="2026-01-01")

# after
# chunk by year so each request is far below the count cap
frames = []
for (s, e) in split_year_ranges("2020-01-01", "2026-01-01"):
    frames.append(tickflow_fetcher.get_stock_history_with_limit("600519", start=s, end=e))
df = pd.concat(frames, ignore_index=True).drop_duplicates(subset="date")

Defensive patterns

Strategy: validation

Validate before calling

# keep requested trading-day count safely below the cap before calling
trading_days = estimate_trading_days(start_date, end_date)
cap = tickflow_fetcher._daily_kline_count(start_date, end_date)
assert trading_days < cap, f"range too wide ({trading_days} days); split into chunks"

Try / catch

try:
    df = tickflow_fetcher.get_stock_data(code, start, end)
except DataFetchError as e:
    if "truncated by count" in str(e):
        df = pd.concat(
            [tickflow_fetcher.get_stock_data(code, s, en) for (s, en) in split_ranges(start_date, end_date, months=12)],
            ignore_index=True,
        ).drop_duplicates(subset="date")
    else:
        raise

Prevention

Cap per-request date windows (e.g. <= 1 year) so responses cannot hit the count limit.
Never ignore this error — truncated history silently corrupts indicators and backtests.
After chunked fetches, verify continuity against a trading calendar.

When it happens

Trigger: Requesting a date range whose trading-day count (computed by _daily_kline_count) reaches the count limit sent to client.klines.get; the API returns exactly `count` rows, so it is impossible to tell whether more data existed beyond the cap.

Common situations: Long lookback windows (multi-year backtests) exceeding the per-request cap; count estimation too tight for ranges with many trading days; API changing pagination semantics so count no longer caps server-side.

Related errors

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