From 03f8dd9afea7c61c4982cc259aa6da61bc12223e Mon Sep 17 00:00:00 2001
From: admin <admin@c5ai.ch>
Date: Sun, 24 May 2026 14:25:00 +0200
Subject: [PATCH] Phase2: Invoicecomputation/AdminpricingUI/Ainvoicemgnt

---
 .../admin/billing/invoices/[id]/pdf/route.ts  | 20 ++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/app/api/admin/billing/invoices/[id]/pdf/route.ts b/src/app/api/admin/billing/invoices/[id]/pdf/route.ts
index 1ce0b8b..0a7284e 100644
--- a/src/app/api/admin/billing/invoices/[id]/pdf/route.ts
+++ b/src/app/api/admin/billing/invoices/[id]/pdf/route.ts
@@ -26,15 +26,17 @@ export async function GET(
   if (!pdf) {
     return new NextResponse("Not found", { status: 404 });
   }
-  // Web `Response`'s `BodyInit` doesn't include Node's `Buffer` — pg
-  // returns bytea as Buffer but Next/the runtime want a BufferSource.
-  // Wrap into a zero-copy Uint8Array view (Buffer extends Uint8Array
-  // under the hood, but TypeScript treats them as distinct).
-  const body = new Uint8Array(
-    pdf.data.buffer,
-    pdf.data.byteOffset,
-    pdf.data.byteLength
-  );
+  // Web `Response`'s BodyInit accepts BufferSource, which IS satisfied
+  // by a Uint8Array. But the pg-returned Buffer types as
+  // `Uint8Array<ArrayBufferLike>` (the @types/node 22+ generic form),
+  // and lib.dom's BufferSource only accepts `Uint8Array<ArrayBuffer>` —
+  // the narrower concrete form. The variance kills assignability,
+  // even though Buffer extends Uint8Array at runtime.
+  //
+  // `Uint8Array.from(buf)` allocates a fresh typed array; the result
+  // is `Uint8Array<ArrayBuffer>` (concrete generic), which BodyInit
+  // accepts. Copy cost is trivial at PDF sizes.
+  const body = Uint8Array.from(pdf.data);
   return new NextResponse(body, {
     status: 200,
     headers: {