fix(admin): materialise segment CASE via subquery in getMultiYearGapTrend

The previous workforce/NAF query inlined the CASE expression directly
in SELECT, GROUP BY and ORDER BY. Drizzle re-binds fresh
parameter placeholders (`$1..$6`, `$10..$15`, `$16..$21`) at each
call site, so Postgres sees three textually different expressions and
rejects the query with 'column must appear in the GROUP BY clause'.

Push the CASE into an inner subquery aliased `gap_trend_src.segment`,
then aggregate on the alias in the outer query. Parameters are bound
exactly once, the outer GROUP BY / ORDER BY only references column
names, and the Postgres planner is happy.

No observable behaviour change for consumers. Fixes the 500 the user
was hitting in local dev when selecting 'Segmenter par NAF'.

Author: LucasCharrier

packages/app/src/server/api/routers/__tests__/adminStats.test.ts

@@ -306,8 +306,14 @@ type TrendRow = {
 };
 
 /**
- * Build a DB mock matching the getMultiYearGapTrend chain:
- * select → from → optional innerJoin → where → groupBy → orderBy (resolves).
+ * Build a DB mock matching the getMultiYearGapTrend chain. The workforce /
+ * NAF branch runs two queries: an inner `select → from → innerJoin → where
+ * → as()` that materialises the CASE-derived segment column, then an outer
+ * `select → from → groupBy → orderBy (resolves)` that aggregates on the
+ * subquery alias. The global branch only runs the final aggregating chain
+ * (no innerJoin when there are no filters). A single chained mock covers
+ * both shapes — every method returns `this` so the graph can be walked in
+ * any order before `orderBy` resolves with the seeded rows.
  */
 function buildTrendDb(rows: TrendRow[]) {
 	const orderBy = vi.fn().mockResolvedValue(rows);
@@ -317,6 +323,7 @@ function buildTrendDb(rows: TrendRow[]) {
 		where: vi.fn().mockReturnThis() as ReturnType<typeof vi.fn>,
 		groupBy: vi.fn().mockReturnThis() as ReturnType<typeof vi.fn>,
 		orderBy,
+		as: vi.fn().mockReturnThis() as ReturnType<typeof vi.fn>,
 	};
 	return {
 		select: vi.fn().mockReturnValue(chain),

packages/app/src/server/api/routers/adminStats.ts

@@ -237,22 +237,35 @@ export const adminStatsRouter = createTRPCRouter({
 				];
 			}
 
-			// Workforce / NAF modes: the segment column is a CASE expression
-			// (a real expression, not a constant), so Postgres is happy to see
-			// it in both SELECT and GROUP BY.
+			// Workforce / NAF modes: the segment column is a CASE expression.
+			// We *must* compute it once in an inner subquery and reference the
+			// alias from the outer aggregation. Inlining the CASE in SELECT +
+			// GROUP BY + ORDER BY directly makes Drizzle re-bind fresh `$N`
+			// parameters at each call site — Postgres then sees three textually
+			// different CASE expressions and rejects the GROUP BY with
+			// "column must appear in the GROUP BY clause".
 			const segmentExpr = buildSegmentExpression(input.segmentBy);
-			const rows = await ctx.db
+			const innerSub = ctx.db
 				.select({
 					year: declarations.year,
-					segment: segmentExpr,
-					avgGap: sql<string | null>`avg(${declarations.averageGap})`,
-					sampleSize: sql<number>`count(*)::int`,
+					segment: segmentExpr.as("segment"),
+					averageGap: declarations.averageGap,
 				})
 				.from(declarations)
 				.innerJoin(companies, eq(declarations.siren, companies.siren))
 				.where(and(...filters))
-				.groupBy(declarations.year, segmentExpr)
-				.orderBy(declarations.year, segmentExpr);
+				.as("gap_trend_src");
+
+			const rows = await ctx.db
+				.select({
+					year: innerSub.year,
+					segment: innerSub.segment,
+					avgGap: sql<string | null>`avg(${innerSub.averageGap})`,
+					sampleSize: sql<number>`count(*)::int`,
+				})
+				.from(innerSub)
+				.groupBy(innerSub.year, innerSub.segment)
+				.orderBy(innerSub.year, innerSub.segment);
 
 			return buildTrendSeries(rows);
 		}),