[AZ-492] Cycle 3 batch 4: perf harness PT-07 + PT-08 + JWT-attach
ci/woodpecker/push/01-test Pipeline was successful
ci/woodpecker/push/02-build-push Pipeline was successful

Drains all three deferred perf-harness items in one batch:
- PT-01..PT-06 now carry Authorization: Bearer minted via the canonical
  SatelliteProvider.TestSupport.JwtTokenFactory (AZ-491) — no third copy
  of JWT logic in the shell.
- PT-07 implemented as cold + warm dual-pass distribution (N=20 each),
  reports p50/p95 for both passes and fails if warm p95 >= cold p95.
- PT-08 implemented as 20-batch upload distribution with batch p95 gated
  at the AZ-488 2000 ms target; per-item gate cost reported as derived
  proxy (batch_p95 / batch_size).

New SatelliteProvider.IntegrationTests/PerfBootstrap.cs adds two CLI
short-circuit subcommands (--mint-only and --gen-uav-fixture <path>)
invoked by the shell so the perf script never inlines the JWT or
JPEG-fixture logic. The dispatch sits at the top of Program.cs Main
and runs before any HTTP / DB / readiness setup.

performance-tests.md PT-07 + PT-08 flip from Deferred to Implemented.
traceability-matrix.md PT-07 + PT-08 rows move from recorded to covered
(PT-08 partial due to per-item proxy — flagged Low in batch-4 review).
_docs/_process_leftovers/2026-05-11_perf-pt07-harness.md deleted; the
leftovers directory is now empty.

Closes cycle-2 retro Action 2; LESSONS.md [process] rule about Deferred
NFRs remains in force as a guardrail.

Also includes the previously-uncommitted cumulative review report for
cycle-3 batches 01-03 (generated at the end of batch 3 but not staged).

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-05-12 01:52:25 +03:00
parent 745f4840e6
commit 080441db5d
14 changed files with 715 additions and 76 deletions
@@ -1,47 +0,0 @@
# Leftover — PT-07 perf harness + cycle 1 perf run
- **Timestamp**: 2026-05-11T07:05:00Z
- **Origin**: autodev cycle 1, Step 15 (Performance Test)
- **Blocker class**: non-user-input — work was deferred at the Step 15 user gate; no missing user decision blocks completion.
## What was deferred
1. **PT-07 implementation** in `scripts/run-performance-tests.sh`: capture pre-change baseline for `GetTilesByRegionAsync` p95 latency, run post-change measurement, compute the ratio, and assert `ratio ≤ 1.10`. PT-07 was recorded as a documentation entry during Step 12 (`_docs/02_document/tests/performance-tests.md` + `traceability-matrix.md` "NFRs → Test Mapping" section) but the runner script does not yet have the corresponding scenario.
2. **Active perf run** of PT-01..PT-06 against the post-AZ-484 build. The runner exists; it requires `docker-compose up` on the dev host. Not executed this cycle (per the meta-rule "ask before kicking off Docker / long-running perf operations").
## Why it is safe to defer
- AZ-484 functional correctness validated by 5 dedicated AZ-484 integration tests (Step 11). The DB read paths exercised by PT-07 are the same ones exercised by `MostRecentAcrossSourcesSelection_AZ484_AC2` etc.
- The post-AZ-484 SQL uses the same `idx_tiles_unique_location_source` index as the contract specifies; structurally there is no new full scan, join, or lock added vs. pre-AZ-484.
- Cycle 1 perf run is recorded as `Unverified` (not `Fail`) per the test-run perf-mode rules — gate does not block deploy.
## Replay actions for next /autodev invocation
When the next cycle's autodev runs, before any new tracker write or before re-entering Step 15 in cycle 2:
1. Add PT-07 to `scripts/run-performance-tests.sh`:
- Capture a pre-change baseline by checking out the parent of the AZ-484 commit (`git rev-parse HEAD~N` where N points at the AZ-484 batch), running the existing PT-03/PT-04 region scenarios, and recording the `GetTilesByRegionAsync` timings (the repository already logs slow query warnings at >500 ms — extend that log line to include median/p95 captured per call window).
- Run the post-change measurement against the current `HEAD`.
- Compute the p95 ratio and fail when `> 1.10`.
2. Bring up the docker stack (`docker-compose up --build -d`) and run the full perf script with the user's explicit go-ahead.
3. Capture results into `_docs/06_metrics/perf_<YYYY-MM-DD>_cycle<N>.md`.
4. Once results are recorded, delete this leftover file.
## AZ-488 follow-on: PT-08 (UAV upload latency)
The AZ-488 commit added PT-08 (UAV tile batch upload latency) to `_docs/02_document/tests/performance-tests.md` with Status `Deferred` because it reuses the same harness expansion as PT-07 (baseline capture + p95 ratio). When PT-07's runner-script scenario is implemented in step 1 above, add the PT-08 scenario in the **same commit** — the integration-test fixtures already exist (`SatelliteProvider.IntegrationTests/UavUploadTests` happy-path JWT + `UavTileImageFactory.CreateRandomJpeg`). After PT-08 runs, flip the Status line in `performance-tests.md` from `Deferred` to active. This keeps cycle 1 retro Action 2 satisfied for both NFRs.
## AZ-487 follow-on: scripts/run-performance-tests.sh attaches no Bearer token (cycle 2 carry-over)
Cycle 2's Step 15 (Performance Test) skip-decision uncovered an additional latent blocker: `scripts/run-performance-tests.sh` calls every `/api/satellite/*` endpoint without an `Authorization` header. Post-AZ-487 every such call returns HTTP 401 — the script is currently broken end-to-end, not just for PT-07/PT-08. Whoever picks up the harness work in step 1 above MUST also:
1. Read `JWT_SECRET` from the host env (the same value used by `docker-compose.yml`).
2. Mint a short-lived HS256 token at the top of the script (mirror `SatelliteProvider.IntegrationTests/JwtTestHelpers.MintValidToken` — small `python3 -c` or `jwt` CLI call; do not commit the dev placeholder secret).
3. Add the token to every `curl` invocation via `-H "Authorization: Bearer $JWT"`.
4. Skip-the-test-cleanly when `JWT_SECRET` is unset rather than running and failing on every call.
This is purely script work; no production code needs to change. Tracking it here so PT-01..PT-06 are runnable again the same cycle PT-07/PT-08 are activated.
## Tracker action (none required this cycle)
This leftover does NOT require a Jira ticket on its own — it tracks deferred process work, not user-visible scope. If the perf comparison reveals a regression next cycle, that finding will create a Jira bug; until then there is nothing to file.