@biffo/cli 0.253.3 → 0.253.5

package/_skeletons/sibling-template/apps/frontend/src/lib/api-client.test.ts

@@ -34,11 +34,52 @@ describe('extractErrorMessage', () => {
     expect(extractErrorMessage('{"message":"nope"}', 'Bad Request')).toBe('{"message":"nope"}')
   })
 
-  it('falls back to the raw text when detail is not a string', () => {
+  // Renamed from "falls back to the raw text when detail is not a string" —
+  // that name generalised a decision only ever made about a LIST `detail`
+  // (biffo-template#1350). It is no longer true of every non-string detail: a
+  // dict carrying a string `message` (below) now unwraps instead of falling
+  // back. FastAPI's own 422 is the case this test still pins.
+  it('falls back to the raw text when detail is a list (FastAPI 422 field errors)', () => {
     const body = '{"detail":[{"loc":["body","x"],"msg":"bad"}]}'
     expect(extractErrorMessage(body, 'Unprocessable Entity')).toBe(body)
   })
 
+  // The browser-side twin of `_extract_detail`'s identical rule in
+  // core_client.py. Core's generic CRUD layer answers an integrity error with
+  // `{"detail": {"message": "...", "constraint": "..."}}`
+  // (`routing/crud_handlers._integrity_error_response`); until this rule
+  // existed here, that shape fell straight through to the raw JSON blob, even
+  // in a sibling whose BFF had already unwrapped it server-side
+  // (biffo-template#1350, tabsii-crm#272).
+  it('unwraps a dict detail carrying a string message', () => {
+    const body =
+      '{"detail":{"message":"course c1 cannot be deleted: 3 enrolment(s) depend on it.","constraint":"fk_enrolments_course_id"}}'
+    expect(extractErrorMessage(body, 'Conflict')).toBe(
+      'course c1 cannot be deleted: 3 enrolment(s) depend on it.',
+    )
+  })
+
+  // `constraint` is deliberately dropped, not appended, in EVERY case — a
+  // database object name is schema reconnaissance (tabsii-platform#473) and
+  // says nothing to the person reading the sentence. This asserts the drop
+  // rather than just the unwrap above, so a future "helpfully" append would
+  // fail here even if it left the previous test passing.
+  it('drops constraint rather than appending it to the message', () => {
+    const body = '{"detail":{"message":"cannot delete","constraint":"fk_enrolments_course_id"}}'
+    const message = extractErrorMessage(body, 'Conflict')
+    expect(message).toBe('cannot delete')
+    expect(message).not.toContain('fk_enrolments_course_id')
+  })
+
+  // Only the declared `message` key is trusted. A dict `detail` with no
+  // `message` is a shape nobody has declared, so it falls back to the raw
+  // text — same posture as the list case above — rather than inventing a
+  // summary that could hide information the caller had before.
+  it('falls back to the raw text when a dict detail has no message', () => {
+    const body = '{"detail":{"constraint":"fk_enrolments_course_id"}}'
+    expect(extractErrorMessage(body, 'Conflict')).toBe(body)
+  })
+
   it('uses the status text when the body is empty', () => {
     expect(extractErrorMessage('', 'Internal Server Error')).toBe('Internal Server Error')
   })

package/_skeletons/sibling-template/apps/frontend/src/lib/api-client.ts

@@ -30,9 +30,22 @@ export class ApiError extends Error {
  * - **Parsed, never assumed.** A non-JSON body (a proxy timeout page, a
  *   CloudFront error), or JSON with no `detail`, falls back to the raw text
  *   unchanged — so this can never hide information the caller had before.
- * - **A non-string `detail` also falls back.** FastAPI's own 422 makes
- *   `detail` a list of field errors; picking something out of it would just
- *   move the problem rather than fix it.
+ * - **A dict `detail` carrying a string `message` unwraps to that message.**
+ *   Core's generic CRUD layer answers an integrity error with
+ *   `{"detail": {"message": "...", "constraint": "..."}}`
+ *   (`routing/crud_handlers._integrity_error_response`). Until this rule
+ *   existed here, a sibling whose BFF had already unwrapped this shape
+ *   (`core_client.py`) still rendered the raw JSON blob in the browser,
+ *   because this layer only knew how to unwrap a *string* `detail`
+ *   (biffo-template#1350). `constraint` is deliberately dropped, not
+ *   appended — it is a database object name, which is schema
+ *   reconnaissance (tabsii-platform#473) and says nothing to the person
+ *   reading the sentence.
+ * - **Any other non-string, non-message-bearing `detail` still falls
+ *   back.** FastAPI's own 422 makes `detail` a list of field errors, and a
+ *   dict `detail` with no `message` key is a shape nobody has declared —
+ *   picking something out of either would move the problem rather than fix
+ *   it.
  *
  * The one addition over the Python version: an empty body yields the HTTP
  * status text, because a browser rendering `''` shows the user nothing at all.
@@ -66,10 +79,25 @@ function parsedDetail(body: string): string | null {
   }
   if (typeof parsed === 'object' && parsed !== null && 'detail' in parsed) {
     const { detail } = parsed
-    // A non-string `detail` also falls back. FastAPI's own 422 makes it a list
-    // of field errors; picking something out of it would move the problem
-    // rather than fix it.
     if (typeof detail === 'string') return detail
+    // A dict `detail` carrying a string `message` unwraps to that message —
+    // the browser-side twin of `_extract_detail`'s identical rule in
+    // core_client.py (biffo-template#1350). `constraint` is deliberately
+    // dropped, not appended: it is a database object name (schema
+    // reconnaissance, tabsii-platform#473) and says nothing to the person
+    // reading the sentence. Only the declared `message` key is trusted — a
+    // dict `detail` with anything else (no `message`, or a non-string one),
+    // or a non-dict non-string `detail` (FastAPI's own 422 makes it a list
+    // of field errors), falls through to the raw text below rather than
+    // inventing a summary from a shape nobody has declared.
+    if (
+      typeof detail === 'object' &&
+      detail !== null &&
+      !Array.isArray(detail) &&
+      typeof (detail as { message?: unknown }).message === 'string'
+    ) {
+      return (detail as { message: string }).message
+    }
   }
   return null
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@biffo/cli",
-  "version": "0.253.3",
+  "version": "0.253.5",
   "description": "Biffo project scaffolding CLI",
   "license": "MIT",
   "type": "module",

package/scripts/wait-for-checks.sh

@@ -37,6 +37,27 @@
 #    same count seen on two consecutive polls — so a fast check concluding while
 #    slower ones are still registering does not end the wait early.
 #
+# ## A re-run does not replace its old entry, and `statusCheckRollup` never drops it
+#
+# `statusCheckRollup` returns **every** check run against the PR's head commit,
+# including ones a later run has superseded — a re-run adds a second row under
+# the same name rather than replacing the first. Read naively, a check that
+# failed once and was then fixed by a re-run still shows a FAILURE row forever,
+# so "any row with a FAILURE conclusion" reports the wrong thing on exactly the
+# PRs most likely to need this script: anything that failed and was corrected.
+# GitHub's own merge gate, and `gh pr checks`, both resolve a required context to
+# the **latest** run of that name — this script has to do the same, or it
+# disagrees with the authority it exists to reflect (#1333, class #1362).
+#
+# So the rollup is deduped by name, keeping the entry with the latest
+# `completedAt`/`startedAt` (falling back to `updatedAt`/`createdAt` for a plain
+# commit status, which carries no `startedAt`/`completedAt` at all), **before**
+# any conclusion is evaluated. Same `group_by | max_by(latest timestamp)` shape
+# `branch-health.sh` already uses for its per-workflow rollup — that script reads
+# `gh run list`, whose rows are one per distinct run rather than per check name,
+# so it was never exposed to this defect, but the resolution method is the same
+# one worth keeping consistent.
+#
 # ## Exit codes, and why 2 exists
 #
 #   0  every required/observed check concluded, none failed
@@ -200,9 +221,14 @@ while :; do
   rollup=$(gh_pr view "$PR" --json statusCheckRollup --jq '
     [ .statusCheckRollup[]?
       | { name:  (.name // .context),
-          state: (.conclusion // .state // (if .status == "COMPLETED" then "" else null end))
+          state: (.conclusion // .state // (if .status == "COMPLETED" then "" else null end)),
+          when:  (.completedAt // .startedAt // .updatedAt // .createdAt // "")
         }
-    ] | .[] | "\(.name)\t\(.state // "")"') || rollup=""
+    ]
+    | group_by(.name)
+    | map(max_by(.when))
+    | .[]
+    | "\(.name)\t\(.state // "")"') || rollup=""
 
   count=0
   [ -n "$rollup" ] && count=$(printf '%s\n' "$rollup" | grep -c .)