sansan0/TrendRadar · critical · RuntimeError

数据一致性检查失败：保存后立即读取失败

Error message

数据一致性检查失败：保存后立即读取失败

What it means

Raised by trendradar's main pipeline after it saves a data file and immediately fails to read it back. This is a self-check (write-then-read consistency guard): the save path reported success but the subsequent load returned nothing usable, so the run aborts with RuntimeError rather than silently continuing with missing historical data.

Source

Thrown at trendradar/__main__.py:1488

                    filter_words,
                    historical_id_to_name,
                    failed_ids=failed_ids,
                    global_filters=global_filters,
                    rss_items=rss_items,
                    rss_new_items=rss_new_items,
                    standalone_data=standalone_data,
                    schedule=schedule,
                    rss_new_urls=rss_new_urls,
                )

                combined_id_to_name = {**historical_id_to_name, **id_to_name}
                new_titles = historical_new_titles
                id_to_name = combined_id_to_name
                title_info = historical_title_info
                results = all_results
            else:
                print("❌ 严重错误：无法读取刚保存的数据文件")
                raise RuntimeError("数据一致性检查失败：保存后立即读取失败")
        elif self.report_mode == "daily":
            # daily 模式：使用全天累计数据
            analysis_data = self._load_analysis_data()
            if analysis_data:
                (
                    all_results,
                    historical_id_to_name,
                    historical_title_info,
                    historical_new_titles,
                    _,
                    _,
                    _,
                ) = analysis_data

                # 使用历史数据准备独立展示区数据（包含完整的 title_info）
                standalone_data = self._prepare_standalone_data(
                    all_results, historical_id_to_name, historical_title_info, raw_rss_items
                )

View on GitHub (pinned to 8ee26026ba)

Solutions

1. Check disk space and permissions on the data directory; a truncated write is the most common cause.
2. Run trendradar from a consistent working directory (or set the relevant path env vars absolutely) so save and load resolve the same file.
3. Ensure only one trendradar instance runs against the same data directory.
4. Exclude the data directory from sync/antivirus scanning, then rerun.
5. If it persists, inspect the save function's flush/fsync logic — the file may not be committed before the read.

data_path = Path(os.environ.get("TRENDRADAR_DATA_DIR", "data"))
if not data_path.is_dir() or os.access(data_path, os.W_OK | os.R_OK):
    # writable check
    if not (data_path.is_dir() and os.access(data_path, os.W_OK)):
        raise OSError(f"data dir not writable: {data_path}")
# also verify free space
import shutil
if shutil.disk_usage(data_path).free < 50 * 1024 * 1024:
    raise OSError("less than 50MB free")

for attempt in range(2):
    try:
        run_trendradar()
        break
    except RuntimeError as e:
        if "数据一致性检查失败" in str(e) and attempt == 0:
            continue  # one retry: transient fs/sync interference
        raise

When it happens

Trigger: Running trendradar in an on-demand/merged report mode where results are persisted and then reloaded within the same run; the reload returns falsy/none. Causes include the file being written to a different path than read (cwd change between save and load), an external process locking/removing the file, disk-full producing a truncated file, or a save function returning success without flushing.

Common situations: Running the CLI from a different working directory so relative data paths diverge; antivirus/sync tools (Dropbox, OneDrive) touching the file between write and read; near-full disk; concurrent trendradar instances writing the same data file.

Related errors

• week_map 缺少星期映射: {weekday}
• week_map[{weekday}] 引用了不存在的 day_plan: {day_plan_key}
• day_plan '{plan_key}' 中时间段 '{ranges[i][0]}' ({ranges[i][1]}-

AI-assisted analysis of sansan0/TrendRadar@8ee26026ba (2026-08-15). Data as JSON: /api/errors/c5af101025baf0b2. Report an issue: GitHub.