@vxil/config 0.5.1 → 0.6.0

package/dist/index.d.ts

@@ -106,6 +106,26 @@ export interface CollectionDef {
  *   session.revoked — auth.session.revoked { user_id, session_id, reason }
  *   signin.failure  — auth.signin.failure { email_hash | user_id, reason } */
 export type AuthHookEvent = 'user.created' | 'session.created' | 'session.revoked' | 'signin.failure';
+/** The opt-in re-delivery of a platform-delivered trigger (F33, 2026-09-25).
+ *  DEFAULT OFF: the platform acknowledges every delivery with a 200 whatever
+ *  the handler returned — an application error is observed (`functions.run.failed`),
+ *  never re-delivered. With `retry` set on a `queue` / `webhook` / `cmsHook` /
+ *  `authHook` trigger, a non-2xx answer of the handler is handed back to the
+ *  jobs retry ladder instead (60 s, 120 s, … backoff) and the last failed
+ *  attempt dead-letters the run (`job.dead_lettered`, replayable from the
+ *  Jobs page). Each attempt is a billed invocation and carries the SAME
+ *  `idempotency_key` — dedupe on it. Effective attempts =
+ *  min(maxAttempts, the project's `jobs.retry.defaultMaxAttempts`, default 5).
+ *  A handler that partially writes and then fails re-fires its downstream
+ *  events on EVERY attempt, so the chain is a tree (up to maxAttempts children
+ *  per hop): the causal-depth guard bounds its length (32 hops), not its size —
+ *  the breaker, the loop guard, the dead-letter quota and the daily share do.
+ *  Write only once you will return 2xx, or dedupe on idempotency_key. Not accepted on `http` (it returns its
+ *  real status to its caller) or `cron` (a retry would overlap the next tick). */
+export interface FunctionTriggerRetry {
+    /** 1–5 attempts in all (1 = a failed attempt dead-letters at once, no re-delivery) */
+    maxAttempts: number;
+}
 /** A function trigger (the §7.3 crossing). cmsHook fires on a CMS write;
  * authHook fires on ONE auth lifecycle event (default `user.created` — the
  * post-signup hook; at-least-once, ~1min fanout latency). */
@@ -118,6 +138,7 @@ export type FunctionTrigger = {
 } | {
     kind: 'queue';
     source: string;
+    retry?: FunctionTriggerRetry;
 }
 /** `webhook`: the function is woken by a webhook_subscription fan-out whose
  *  target_url is `<edge>/v1/internal/fn/trigger/<name>?tenant=<id>`. That
@@ -132,6 +153,7 @@ export type FunctionTrigger = {
  | {
     kind: 'webhook';
     source: string;
+    retry?: FunctionTriggerRetry;
 }
 /** `cmsHook`: fires after a CMS write in `collection`. The platform filters
  *  deliveries on the binding (2026-09-19): `beforeCreate` → created only,
@@ -142,15 +164,26 @@ export type FunctionTrigger = {
     kind: 'cmsHook';
     collection: string;
     event: 'beforeCreate' | 'beforeUpdate' | 'beforeWrite';
+    retry?: FunctionTriggerRetry;
 } | {
     kind: 'authHook';
     event?: AuthHookEvent;
+    retry?: FunctionTriggerRetry;
 };
 /** A deployed tenant function — source in functions/, deployed on `vxil push`. */
 export interface FunctionDef {
     /** path to the ES-module entrypoint, e.g. ./functions/<name>.ts */
     entry: string;
     trigger?: FunctionTrigger;
+    /** Further bindings beside `trigger` (2026-09-25): a function is code + a SET
+     *  of trigger bindings, so one bundle can be reached by several front doors —
+     *  a webhook AND a cron, an http door AND a cmsHook. `trigger` and `triggers`
+     *  may both be present; the deploy carries them in that order as
+     *  `bindings[]`, at most 8 in all (the CLI refuses a 9th before the wire).
+     *  Every binding lands the same isolate; only the envelope's `trigger` /
+     *  `payload` differ. Each platform-delivered binding is billed per
+     *  invocation and bounded by the loop guard and the breaker. */
+    triggers?: FunctionTrigger[];
     /** clamped by DENY_FUNCTION_SCOPES at deploy (admin, wildcard, features:write,
      *  functions:write, secrets:write rejected; payments:write / notifications:send /
      *  users:* allowed as owner-granted business scopes). */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vxil/config",
-  "version": "0.5.1",
+  "version": "0.6.0",
   "description": "Typed vxil.config.ts authoring for the vxil backend platform — defineConfig, feature and cms field definitions (published for @vxil/cli).",
   "license": "MIT",
   "homepage": "https://vxil.com",
@@ -22,7 +22,7 @@
     "src"
   ],
   "dependencies": {
-    "@vxil/feature-configs": "0.5.1"
+    "@vxil/feature-configs": "0.6.0"
   },
   "publishConfig": {
     "access": "public"

package/src/index.ts

@@ -130,13 +130,34 @@ export interface CollectionDef {
  *   signin.failure  — auth.signin.failure { email_hash | user_id, reason } */
 export type AuthHookEvent = 'user.created' | 'session.created' | 'session.revoked' | 'signin.failure';
 
+/** The opt-in re-delivery of a platform-delivered trigger (F33, 2026-09-25).
+ *  DEFAULT OFF: the platform acknowledges every delivery with a 200 whatever
+ *  the handler returned — an application error is observed (`functions.run.failed`),
+ *  never re-delivered. With `retry` set on a `queue` / `webhook` / `cmsHook` /
+ *  `authHook` trigger, a non-2xx answer of the handler is handed back to the
+ *  jobs retry ladder instead (60 s, 120 s, … backoff) and the last failed
+ *  attempt dead-letters the run (`job.dead_lettered`, replayable from the
+ *  Jobs page). Each attempt is a billed invocation and carries the SAME
+ *  `idempotency_key` — dedupe on it. Effective attempts =
+ *  min(maxAttempts, the project's `jobs.retry.defaultMaxAttempts`, default 5).
+ *  A handler that partially writes and then fails re-fires its downstream
+ *  events on EVERY attempt, so the chain is a tree (up to maxAttempts children
+ *  per hop): the causal-depth guard bounds its length (32 hops), not its size —
+ *  the breaker, the loop guard, the dead-letter quota and the daily share do.
+ *  Write only once you will return 2xx, or dedupe on idempotency_key. Not accepted on `http` (it returns its
+ *  real status to its caller) or `cron` (a retry would overlap the next tick). */
+export interface FunctionTriggerRetry {
+  /** 1–5 attempts in all (1 = a failed attempt dead-letters at once, no re-delivery) */
+  maxAttempts: number;
+}
+
 /** A function trigger (the §7.3 crossing). cmsHook fires on a CMS write;
  * authHook fires on ONE auth lifecycle event (default `user.created` — the
  * post-signup hook; at-least-once, ~1min fanout latency). */
 export type FunctionTrigger =
   | { kind: 'http'; path?: string }
   | { kind: 'cron'; schedule: string }
-  | { kind: 'queue'; source: string }
+  | { kind: 'queue'; source: string; retry?: FunctionTriggerRetry }
   /** `webhook`: the function is woken by a webhook_subscription fan-out whose
    *  target_url is `<edge>/v1/internal/fn/trigger/<name>?tenant=<id>`. That
    *  subscription is AUTO-WIRED on deploy (2026-09-19): the platform reconciles
@@ -147,20 +168,29 @@ export type FunctionTrigger =
    *  also enforced at delivery: a non-matching event is ACK-200 skipped.
    *  Declaring the binding is what opts the function into event delivery; a
    *  receiver that declares only `cron` keeps the older cron+{} wake. */
-  | { kind: 'webhook'; source: string }
+  | { kind: 'webhook'; source: string; retry?: FunctionTriggerRetry }
   /** `cmsHook`: fires after a CMS write in `collection`. The platform filters
    *  deliveries on the binding (2026-09-19): `beforeCreate` → created only,
    *  `beforeUpdate` → updated only, `beforeWrite` → created|updated; a write to
    *  another collection never wakes the function. Deleted/bulk events are not
    *  delivered to a cmsHook binding. */
-  | { kind: 'cmsHook'; collection: string; event: 'beforeCreate' | 'beforeUpdate' | 'beforeWrite' }
-  | { kind: 'authHook'; event?: AuthHookEvent };
+  | { kind: 'cmsHook'; collection: string; event: 'beforeCreate' | 'beforeUpdate' | 'beforeWrite'; retry?: FunctionTriggerRetry }
+  | { kind: 'authHook'; event?: AuthHookEvent; retry?: FunctionTriggerRetry };
 
 /** A deployed tenant function — source in functions/, deployed on `vxil push`. */
 export interface FunctionDef {
   /** path to the ES-module entrypoint, e.g. ./functions/<name>.ts */
   entry: string;
   trigger?: FunctionTrigger;
+  /** Further bindings beside `trigger` (2026-09-25): a function is code + a SET
+   *  of trigger bindings, so one bundle can be reached by several front doors —
+   *  a webhook AND a cron, an http door AND a cmsHook. `trigger` and `triggers`
+   *  may both be present; the deploy carries them in that order as
+   *  `bindings[]`, at most 8 in all (the CLI refuses a 9th before the wire).
+   *  Every binding lands the same isolate; only the envelope's `trigger` /
+   *  `payload` differ. Each platform-delivered binding is billed per
+   *  invocation and bounded by the loop guard and the breaker. */
+  triggers?: FunctionTrigger[];
   /** clamped by DENY_FUNCTION_SCOPES at deploy (admin, wildcard, features:write,
    *  functions:write, secrets:write rejected; payments:write / notifications:send /
    *  users:* allowed as owner-granted business scopes). */