@norskvideo/ctl-dev-kit 0.1.87 → 0.1.89

package/conventions/integration.yml

@@ -55,12 +55,31 @@ on:
 permissions:
   contents: read
 
-# Key the group on event_name so a push never cancels an in-flight ctl-candidate
-# validation: pushes cancel pushes, candidate validations cancel only newer
-# candidates. A cancelled validation would score as a red at release-collect.
+# A ctl-candidate validation must not be cancellable out of a result, because
+# release-collect scores anything other than a literal success as red — a
+# CANCELLED run included — and answers a red with one re-dispatch.
+#
+# Keying on event_name alone was not enough: every candidate is the SAME event,
+# so they shared a group and cancelled each other, and the re-dispatch cancelled
+# the very run it was asking for. On 2026-09-05 commentary was dispatched four
+# times in thirteen minutes, every run cancelled before it could start on the
+# backlogged pool, and rc-gate/0.1.0-2026-09-05-98e09d1/FAILED was written for a
+# candidate on which nothing had actually failed — while playout, studio and
+# reuters, fast enough to finish inside the window, all went green.
+#
+# So: separate the candidates (client_payload.version — empty on push/PR, which
+# leaves those groups exactly as they were), and do not cancel a dispatch run.
+# A superseded PENDING run is dropped before it starts, fires no
+# report-candidate, and scores nothing — which is why queueing is safe here
+# where cancelling is not. Pushes still cancel pushes.
+#
+# Trade-off, stated: two candidates' validations can now overlap in one repo,
+# and their tiers derive host ports from the same per-slug bands. The bands were
+# moved out of the kernel's ephemeral range (ctl-test-harness 0.1.42); an
+# ephemeral daemon port is the durable answer and is not wired yet.
 concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}
-  cancel-in-progress: true
+  group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}-${{ github.event.client_payload.version }}
+  cancel-in-progress: ${{ github.event_name != 'repository_dispatch' }}
 
 jobs:
   integration:

package/conventions/workflow-shell.ts

@@ -161,3 +161,37 @@ export function jobsMissingTestTempStep(yaml: string): string[] {
   settle();
   return bad;
 }
+
+/** A `ctl-candidate` validation that another candidate, or its own retry, can
+ *  cancel.
+ *
+ *  release-collect scores anything other than a literal success as red — a
+ *  CANCELLED validation included — and answers a red with one re-dispatch. So a
+ *  concurrency group shared across candidates makes the gate eat itself:
+ *  candidate B's dispatch cancels A's in-flight run, A scores red, A retries,
+ *  and that retry cancels B's run. Observed 2026-09-05: commentary dispatched
+ *  four times in thirteen minutes, every run cancelled, and
+ *  `rc-gate/0.1.0-2026-09-05-98e09d1/FAILED` written for a candidate on which
+ *  nothing had actually failed.
+ *
+ *  Both halves are needed. The group must SEPARATE candidates
+ *  (`client_payload.version`), so a different candidate never shares one; and a
+ *  dispatch run must not be cancellable, so a retry queues behind the run it is
+ *  asking for rather than killing it. A superseded PENDING run is dropped
+ *  before it starts, so it fires no `report-candidate` and scores nothing —
+ *  which is why queueing is safe where cancelling is not. */
+export function candidateConcurrencyProblems(yaml: string): string[] {
+  const block = yaml.match(/^concurrency:\n((?:[ \t]+.*\n)+)/m)?.[1] ?? "";
+  const group = block.match(/^\s*group:\s*(.*)$/m)?.[1] ?? "";
+  const cancel = (block.match(/^\s*cancel-in-progress:\s*(.*)$/m)?.[1] ?? "").trim();
+  const problems: string[] = [];
+  if (!/client_payload\.version/.test(group)) {
+    problems.push(
+      "group does not separate candidates: a newer candidate cancels an older validation, which scores red",
+    );
+  }
+  if (cancel === "true") {
+    problems.push("cancel-in-progress is unconditionally true: the re-dispatch cancels the run it is asking for");
+  }
+  return problems;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@norskvideo/ctl-dev-kit",
-  "version": "0.1.87",
+  "version": "0.1.89",
   "type": "module",
   "exports": {
     "./create-product": "./create-product/create-product.ts",

package/testing/INVARIANTS.customer.template.md

@@ -25,13 +25,13 @@ way resolved defaults (segment durations, as-rendered resolutions, output count)
 are guarded too, not only literal fields. When a code comment carries one of
 these rules, cite the ID there too instead of restating the rule.
 
-| ID               | Invariant                                                                                                     | Guarded by                       |
-| ---------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------- |
-| INV-PLAYLIST-001 | This customer serves legacy playlists only — every composed CMAF playlist is non-low-latency, never LL-HLS    | `<slug>/<slug>-invariants.test.ts` |
-| INV-SEG-001      | CMAF segment duration is 4s on every rendition (a resolved default — only guardable via the composed graph)   | `<slug>/<slug>-invariants.test.ts` |
-| INV-OUT-001      | Exactly three delivery rungs in a single named CMAF group, one playlist per rung                              | `<slug>/<slug>-invariants.test.ts` |
-| INV-RES-001      | The delivery resolutions are exactly the ladder the customer signed off (e.g. 1280x720 / 640x360 / 320x180)   | `<slug>/<slug>-invariants.test.ts` |
-| INV-MOQ-001      | The low-latency return / monitor rides MoQ, never a WHIP/RTMP fallback                                        | `<slug>/<slug>-invariants.test.ts` |
+| ID               | Invariant                                                                                                   | Guarded by                         |
+| ---------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------- |
+| INV-PLAYLIST-001 | This customer serves legacy playlists only — every composed CMAF playlist is non-low-latency, never LL-HLS  | `<slug>/<slug>-invariants.test.ts` |
+| INV-SEG-001      | CMAF segment duration is 4s on every rendition (a resolved default — only guardable via the composed graph) | `<slug>/<slug>-invariants.test.ts` |
+| INV-OUT-001      | Exactly three delivery rungs in a single named CMAF group, one playlist per rung                            | `<slug>/<slug>-invariants.test.ts` |
+| INV-RES-001      | The delivery resolutions are exactly the ladder the customer signed off (e.g. 1280x720 / 640x360 / 320x180) | `<slug>/<slug>-invariants.test.ts` |
+| INV-MOQ-001      | The low-latency return / monitor rides MoQ, never a WHIP/RTMP fallback                                      | `<slug>/<slug>-invariants.test.ts` |
 
 The rows above are worked examples (drawn from the datum commentary deployment);
 delete them when seeding a new customer.