[Bug]: #3074 fix incomplete — `summarize_run_info_data` returns unbounded id lists, so `pipeline_runs` still grows with corpus × runs

[mckernanin]

Bug Description

Follow-up to #3074 ("pipeline_runs table grows without bound"), closed by #3075.
The fix caps stringified payloads at MAX_RUN_INFO_DATA_CHARS = 512, but the
Data-list branch returns the full id list with no bound:

# cognee/modules/pipelines/utils/summarize_run_info_data.py (v1.4.1)
if isinstance(data, list) and all(isinstance(item, Data) for item in data):
    return [str(item.id) for item in data]   # <-- unbounded

text = str(data)
if len(text) > MAX_RUN_INFO_DATA_CHARS:      # 512 — only reached for non-Data payloads
    ...

cognify passes exactly such a list — every Data row in the dataset — so
every cognify run persists one UUID per corpus document. The row size grows
linearly with the corpus, and total table growth is corpus size × run rate,
faithfully reproducing the growth #3074 reported — just via the branch the fix
didn't cover.

Steps to Reproduce

1. Run cognee v1.4.1 with DB_PROVIDER=postgres against a dataset of N
   documents.
2. Run cognify repeatedly (each run passes the dataset's full Data list
   into summarize_run_info_data).
3. Inspect pipeline_runs.run_info for the cognify rows: each contains one
   UUID per corpus document, regardless of MAX_RUN_INFO_DATA_CHARS.
4. Watch the table grow by roughly (N × 38 bytes) per run.

Expected Behavior

The #3074/#3075 cap should bound every run_info payload, including the
Data-list branch — e.g. first N ids plus a count:

if isinstance(data, list) and all(isinstance(item, Data) for item in data):
    ids = [str(item.id) for item in data]
    if len(ids) > MAX_RUN_INFO_IDS:
        return ids[:MAX_RUN_INFO_IDS] + [f"... [{len(ids)} ids total]"]
    return ids

Actual Behavior

Observed on a self-hosted v1.4.1 instance (Postgres):

• pipeline_runs: 25,620 rows / 674 MB — second-largest relation in the DB.
• cognify runs: run_info avg 125 KB, max 282 KB. A run from today stored
  7,577 UUIDs (288,549 bytes) — the entire dataset's id list.
• For comparison, add_pipeline rows (which hit the 512-char branch) average
  500 bytes, and memify completions 35 bytes — the cap works everywhere except
  the branch cognify uses.
• Nothing reads the data back: pipeline_runs_pkey and
  ix_pipeline_runs_pipeline_id both show zero index scans in
  pg_stat_user_indexes.

At ~130 cognify runs/day against a ~7.5K-document dataset this table alone adds
~25 MB/day.

Environment

• OS: Linux (Kubernetes, official cognee/cognee:1.4.1 image)
• Python version: as shipped in the image
• Cognee version: 1.4.1
• LLM Provider: not relevant to this issue
• Database: Postgres (DB_PROVIDER=postgres, VECTOR_DB_PROVIDER=pgvector,
  GRAPH_DATABASE_PROVIDER=postgres)

Logs/Error Messages

-- No errors are raised; the symptom is silent table growth.
-- pipeline_runs: 25,620 rows / 674 MB; cognify run_info avg 125 KB, max 282 KB

Additional Context

A retention/pruning policy for pipeline_runs would also help, but the
unbounded branch is the sharp edge.

Pre-submission Checklist

• I have searched existing issues to ensure this bug hasn't been reported already
• I have provided a clear and detailed description of the bug
• I have included steps to reproduce the issue
• I have included my environment details

[MohdMaaz000]

I’d like to contribute to this issue.

I reviewed the reported behavior and the problem appears to be the Data-list branch in summarize_run_info_data.py, which returns every Data.id without applying the existing run-info size bound.

My proposed fix is to bound the serialized IDs using a small, explicit limit and preserve the total item count when truncation occurs, while keeping the existing behavior for lists below the limit.

I would also add regression tests covering:

• a small Data list that remains unchanged
• a large Data list that is truncated
• preservation of the total count in the truncated result
• the existing 512-character behavior for non-Data payloads

If nobody is currently working on this issue, I’d like to take it.