Skip to content

Align report queries with the deployed Athena schema - #4

Closed
bryanfriedman wants to merge 2 commits into
mainfrom
fix/align-with-deployed-schema
Closed

Align report queries with the deployed Athena schema#4
bryanfriedman wants to merge 2 commits into
mainfrom
fix/align-with-deployed-schema

Conversation

@bryanfriedman

@bryanfriedman bryanfriedman commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

What

Three fixes, applied across all ten templates:

1. Wrong table name

Queries read FROM trace. The table is traces.

2. Missing type scoping (double counting)

Run-stage columns are re-emitted by every later-stage trace (apply, add, commit), so WHERE runOutcome IS NOT NULL matches the same run several times.

  • Added type = 'run' to recipe-run-trend, top-recipes.
  • Added type = 'commit' to commit-activity, commit-trend, security-recipe-run-trend, top-recipes-with-commits.
  • Deliberately not added to build-success-trend / build-tool-distribution: they dedupe on buildId, and pinning type = 'build' would undercount builds that only appear in later-stage traces.
  • Deliberately not added to top-users: it reads run and commit columns from the same rows, so a type filter would force commits to zero. It uses only COUNT(DISTINCT ...), so it is already correct.

Bug fix: dashboard KPIs inflated ~4x

dashboard-kpis was the only template mixing raw SUM() with a runOutcome filter that spans four types:

SUM(runEstimatedEffortTimeSavingsMs)   -- summed once per later stage
FROM trace
WHERE runOutcome IS NOT NULL
  • One run that gets applied, added, and committed produces four rows carrying the same value, so estimated_hours_saved and files_changed were inflated up to 4x. Both queries now collapse to one row per (runId, path) (one repository's participation in one run) before aggregating. This is the same class of bug as Deduplicate commit metrics so stage re-emission does not inflate totals #2, which fixed the commit metrics.

Headers and the two affected READMEs were updated so no prose contradicts the new scoping. The build, top-users, and dashboard-kpis notes about later-stage traces are still accurate and were left alone.

Point every report at the `traces` table rather than the placeholder `trace`
name, and pin the tenant with a `<your-tenant>` placeholder so the queries run
against the injected tenant partition.

Add a `type` filter to the six reports that analyze a single command stage, so
partition pruning applies and stage re-emission cannot double count. Leave it
off the build reports, which dedupe on buildId and would undercount if pinned
to type = 'build', and off top-users, which reads run and commit columns from
the same rows.

Fix inflated totals in the dashboard KPIs. Both queries summed run-stage
columns across every trace that re-emits them, counting a single run once per
later stage. Collapse to one row per (runId, path) before aggregating.

Update the affected header comments and READMEs to match the new scoping.
@bryanfriedman
bryanfriedman requested a review from krlittle July 16, 2026 21:31
@bryanfriedman
bryanfriedman marked this pull request as ready for review July 16, 2026 21:31
@bryanfriedman

Copy link
Copy Markdown
Contributor Author

Superseding with #5

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