bug: deck loads all node content into memory, OOM on large databases

[bdougie]

Problem

tapes deck loads every node's full content field into memory via loadSessionCandidates() in pkg/deck/query.go:105-111, regardless of the selected time period. With large databases (200MB+, 57K+ nodes), this causes the process to be OOM-killed.

The query has no WHERE clause on created_at, so even --since 1h loads the entire database first, then filters in memory.

I hit this this morning after a few weeks of consistent usage.

Root cause

Two issues in pkg/deck/query.go:

1. node.FieldContent is included in the Select() (line 106) — the overview dashboard only needs token counts and metadata, not full message content. Some nodes have content fields >2MB (tool results with large file reads).

2. No time-based filtering at the SQL level — the Since/From/To filters from Filters are only applied after all nodes are loaded into memory.

Suggested fix

• Remove node.FieldContent from the Select() in loadSessionCandidates(). Content should only be loaded on-demand when drilling into a specific session.
• Add a WHERE created_at >= ? clause when Filters.Since or Filters.From is set, so the DB only returns relevant nodes.

Impact

Any user with a database over ~100MB will have tapes deck killed by the OS. This is easy to hit after a few weeks of active use.

[linear]

PCC-276

[jpmcb]

tapes deck loads every node's full content field into memory via loadSessionCandidates()

This needs to move to the tapes API which can actually handle paged queries correctly and be served behind a platform: loading the db from the client directly isn't great and won't work once we put this in the cloud (soon ™️ ). I.e., we won't be able to handle tapes deck loading entities itself if there's a hosted tapes somewhere that users are expected to interface with.

[bdougie]

My short term solution is dropping data, but nothing is pressing now that we need to address it.