1 Commits

Include renames

Author	SHA1	Message	Date
Claude Opus 5	8f6357044f	feat(analytics): BI-P018/BI-P019/BI-P021 — execution model, verified cancellation, a budget that stops queries ... BI-P018 — every field the prompt names, plus the one it names by its absence. The record carries `compiled_query_hash` and never the statement, and that is ENFORCED: `assertNoRawSql` runs before any record is emitted and refuses one whose `error` field looks like SQL. The realistic leak is ClickHouse's own error text, which echoes the query — the test uses exactly that string. The recorder writes at EVERY transition, because a recorder that only writes at the end loses precisely the executions worth investigating. Illegal state transitions throw rather than overwrite a terminal row. The one place raw SQL is retained stays BI-P017's analyst statement history, where a privileged human ran unreviewed SQL and "who ran what" must survive. Different record, different retention posture, stated in both files. BI-P019 — "stops" is VERIFIED, not requested. Aborting the client stops US waiting, not the server; KILL QUERY without SYNC tells you nothing; even SYNC can return while the query unwinds. So cancelAndVerify aborts, kills, then POLLS the process list until the query is GONE or the deadline passes — and if the deadline passes it returns `verified_stopped: false` rather than a cheerful `true`. The return type is an outcome object, not a boolean, so a caller cannot mistake "we asked" for "it stopped". An unreachable engine is read as "still running" (fail closed), so the kill is still attempted at the moment an operator most needs it to be. Proven live against ClickHouse 24.8.14.39, with the counterfactual first: * an identical bomb left alone IS still running after 2s — so "gone after we cancelled" is not just "the query was short"; * the cancelled query had read 6,559,476,156 rows, and was verified gone 57ms after the request; * system.query_log records ExceptionWhileProcessing with code 394, QUERY_WAS_CANCELLED — ClickHouse's verdict, not ours. BI-P021 — the honest version. A budget checked once before execution bounds nothing, and the module says so in its first paragraph. ClickHouse's max_rows_to_read bounds ONE query; it cannot express "this tenant may scan X per hour", which is what a budget is for. So enforcement polls the engine's live read_rows/read_bytes counters and CANCELS the running query, through BI-P019 with verification, when window spend would be exceeded. Measured live: a 1,000,000-row window cancelled the query at 130,883,409 rows, 92ms in, verified stopped, code 394. THE OVERSHOOT IS DOCUMENTED, in the module and in the evidence: enforcement is granular to the poll interval, so this is a bound of the form "within roughly one poll interval of engine throughput", not a hard cap. Quoting it as a hard cap would be wrong. Two more things stated rather than implied: * `enforceInFlight: false` is reported by describeEnforcement() as "NOT ENFORCED — this budget is advisory", and the constructor REFUSES to accept enforceInFlight without a process control; * an unshared window store is reported as non-binding across replicas ("with N replicas a tenant can spend up to N times this budget"). * a query the budget killed is still charged for the work it burned. Not charging is how a tenant learns the cheapest query is a cancelled one. Evidence: evidence/bi-p019-p021/cancellation-and-budget.json 268 unit tests, 7 live tests. typecheck + eslint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 02:26:05 +02:00