Fix/performance tab gaps

[notSumit25]

No description provided.

[notSumit25]

What's done

The seven non-blocking findings left over from the Performance-tab readiness review after #86. Each was re-verified against current main before being fixed, and each fix verified after — on the running stack, not by reading the diff.

#	Gap	Fix	Evidence
1	Sample recovery was an unindexable full scan	STORED generated column + text_pattern_ops index	Seq Scan 37.95 ms → Index Scan 0.062 ms on the same data
2	query_lineage never pruned	Added to SlowQueryRetentionService	planted 400d/90d/2d rows → deleted exactly the 2 old ones
3	retry: 3 retried denials	Status predicate on the query client	4 attempts / 7197 ms → 1 / 34 ms
4	Slash in customerId unreachable	Moved the id off the path to a query param	acct/77?x=1 → 200 (old route: 404 raw, 400 encoded)
5	Failed fetch rendered as "no data yet"	Shared QueryError across 6 branches	real 403 now renders an alert with the denial text
6	3 of 4 tabs off-screen at 390px	Scrolling tab bar	scrolls 263px; 4th tab actually clicked at mobile width
7	Workload reads gated on the write tier	assertCanReadConnectionContent	4 reads / 1 write; reads non-403 for a granted user

Three things worth calling out

Two of my own fixes were wrong on the first attempt, and only testing caught them:

• The retry fix did nothing. I read error.response.status, but the axios interceptor rethrows a plain Error with the status on error.status — the predicate never matched and the denied request still made 4 attempts over 7 seconds. Measured in the browser, not inferred.
• The arrow-key handler had a stale closure: selection moved exactly once, then froze. Fixed with the functional state updater.

I nearly shipped a COALESCE fallback on the lineage query "to be safe on older Postgres". Tested it: COALESCE(normalized_match, …) plans a Seq Scan at 48.7 ms vs 0.39 ms for the bare column — it would have silently negated the whole optimization. Removed, with the measurement recorded in the code so nobody re-adds it.

Hands-on QA found a real silent bug (second commit, 06476bf) that reading the code would not have surfaced. Java's normalizeForMatching ends with .trim(); the SQL expression behind the generated column did not. A row stored with leading whitespace normalized to " select ..." in the column and "select ..." in Java, so the prefix LIKE never matched and recovery silently returned the truncated sample. 4 of 1,174 real rows carried such whitespace. The same flaw was in the inline expression this replaces, so it is pre-existing rather than a regression — but silent either way, which is why it survived.

That fix has two parts: btrim(...) in the expression, and stale-column detection in the initializer. A generated column's expression cannot be altered in place and ADD COLUMN IF NOT EXISTS silently keeps whatever is already there, so any install that ran the earlier build would have kept the untrimmed expression forever. It compares pg_get_expr and only drops/re-adds when they differ, so a normal restart doesn't rewrite the table. Verified: restart logged Rebuilding query_lineage.normalized_match: stored expression is out of date, the index survived, affected rows went 4 → 0.

Deliberately not fixed

The slow-log ingestion cursor has two real defects, documented at updateLastProcessed rather than changed:

1. It records when ingestion finished, not the last event's timestamp — so events arriving mid-run are skipped permanently, a gap proportional to run duration.
2. It writes LocalDateTime.now() while every read does .atZone(ZoneOffset.UTC). These agree only because the container runs Etc/UTC; a bare-metal install at UTC+5:30 would skip 5.5 h of history every run (west of UTC it re-ingests duplicates).

All six providers need live cloud credentials to exercise, and an unverified change to an ingestion cursor silently skips or duplicates production data. Better documented than guessed at.

Verification

Backend and frontend both build clean. 21 hands-on QA scenarios run against the local stack — API + direct DB query + real browser via Chrome DevTools MCP, with API/DB/UI agreement required for a pass. Highlights: the slash-id round trip renders SELECT * FROM orders WHERE customer_id = 'acct/77?x=1' in the samples modal; a genuine mid-session grant revocation makes the panel show "You don't have access to this connection's queries. (HTTP 403)" as an assertive alert; 12 adjacent endpoints still 200 (no regressions). All test data cleaned up and both password hashes restored byte-identical.

On the index: at the current 799 rows the planner correctly prefers a seq scan, and idx_scan stays 0 — that is right, not a defect. At 36,456 rows it chooses the Index Scan unprompted (0.038 ms), which is the case the fix targets.

Caveat on CI

mvn test was not run locally (no JDK/Maven on this host). Note that backend tests (advisory) is continue-on-error: true, so a green tick there means the job finished, not that tests passed — main currently has 5 failing test classes independent of this branch. Worth reading the actual test output rather than the check mark.