Skip to content

Safety: hard-cap every run_query response at 10k rows (VFBQUERY_RESULT_ROW_CAP)#66

Merged
Robbie1977 merged 2 commits into
mainfrom
development
Jul 10, 2026
Merged

Safety: hard-cap every run_query response at 10k rows (VFBQUERY_RESULT_ROW_CAP)#66
Robbie1977 merged 2 commits into
mainfrom
development

Conversation

@Robbie1977

Copy link
Copy Markdown
Contributor

No description provided.

Robbie Court added 2 commits July 10, 2026 17:25
…T_ROW_CAP)

Broad terms make many queries huge or unbounded — e.g. AllAlignedImages ~528k,
and ListAllAvailableImages / SubclassesOf / connectivity on high-level classes
(FBbt_00005106 'neuron') return -1/unresolved counts, i.e. potentially millions.
Returning any of those in one response is what caused the 430MB
serialise-on-the-event-loop + websocket broken-pipe blowup.

Bound every run_query (and _dispatch_to_pool) result to RESULT_ROW_CAP rows
(env VFBQUERY_RESULT_ROW_CAP, default 10000; 0 disables), keep the true total in
count, and flag capped so the UI can show 'first N — refine'. No-op for results
that are already small, for AllAlignedImages pages (already <=10k, native
paged), and for non-row payloads like term_info. This makes the service safe
for production against any large/unbounded query, independent of the client.
@Robbie1977 Robbie1977 changed the title Development Safety: hard-cap every run_query response at 10k rows (VFBQUERY_RESULT_ROW_CAP) Jul 10, 2026
@Robbie1977 Robbie1977 merged commit 03529cc into main Jul 10, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant