@hostwebhook/node-types 1.77.0 → 1.79.0

package/dist/respuesta-del-sync.js

@@ -0,0 +1,451 @@
+"use strict";
+/**
+ * La respuesta que recibe quien llama a un webhook en modo `sync`, armada en
+ * UN solo sitio.
+ *
+ * ## Qué problema resuelve
+ *
+ * El dueño quiere unas pestañas para configurar qué recibe el cliente y una
+ * VISTA PREVIA que enseñe los bytes exactos. Una vista previa sólo vale si no
+ * puede desincronizarse del servidor: si son dos implementaciones, el día que
+ * difieran la pantalla miente con toda la confianza del mundo, y miente sobre
+ * lo único que el usuario no puede comprobar desde ahí.
+ *
+ * Ya hay un caso así en el dashboard —`FORMAT_OPTIONS`, cuatro formatos
+ * copiados a mano en `schema-validators/[id]/page.tsx` cuando el paquete
+ * publica dieciocho— y ahí se asume porque desincronizarse AVISA: el campo
+ * deja de ofrecer un formato que sí existe y alguien lo pide. Aquí no avisaría
+ * nada. La previa diría 422 con tres errores, el servidor mandaría otra cosa,
+ * y nadie se enteraría hasta que un cliente se quejara.
+ *
+ * Así que la función de abajo es la ÚNICA que sabe montar estos bytes. La
+ * llaman los tres: el handler del validador en hw-nodes, el endpoint de previa
+ * de la api, y el dashboard para pintarla.
+ *
+ * ## Por qué este paquete y no otro — medido el 2026-09-10
+ *
+ * Los tres candidatos, con los números delante:
+ *
+ * | | `platform-contracts` | `node-sdk` | **`node-types`** |
+ * |---|---|---|---|
+ * | lo pinea el dashboard | `^0.2.0` (0.2.0 instalada) | no es dependencia suya | `^1.74.0` (1.74.0 instalada) |
+ * | ¿el caret llega a lo nuevo? | **NO** — en `0.x` no cruza el minor: habría que subir a `^0.16` a mano | — | **SÍ** — en `1.x` sí lo cruza; basta refrescar el lock |
+ * | dependencias de ejecución | `dependencies: {}` **pero** su barril hace `require('@nestjs/common')` de verdad | mongoose, mongodb, express, re2 (binario nativo) | **ninguna: ni deps ni peers** |
+ * | ¿sirve en el navegador? | **NO** hoy | no | **sí** |
+ * | ficheros del dashboard que ya lo importan | 6 | 0 | **92** |
+ *
+ * ⚠️ Lo de `platform-contracts` conviene leerlo dos veces, porque la primera
+ * medición decía lo contrario. `dependencies: {}` es cierto, y por eso parecía
+ * servible en el navegador. Pero un PEER también se ejecuta: desde 0.3.0 el
+ * paquete trae `servicios/credenciales-del-gateway`, que importa
+ * `BadRequestException` como VALOR, y eso sale en el `dist` como un
+ * `require("@nestjs/common")` al que se llega desde `dist/index.js` —barril de
+ * CommonJS, sin mapa `exports` y sin `sideEffects`, o sea que no se sacude—.
+ * El dashboard entra por ese barril (`lib/store/hooks.ts` pide `tieneAddon`
+ * como valor, no como tipo), así que subirlo metería ~9,5 MB de framework de
+ * servidor —@nestjs/common 1,1 MB, rxjs 8,1 MB, reflect-metadata 265 kB— en un
+ * Next. Lo que NO es el problema, y también se midió: entre 0.2.0 y 0.15.0
+ * `addons.ts` y `operadores.ts` están byte a byte idénticos, así que de los 13
+ * minors de salto NO sale ni un breaking para lo que el dashboard usa hoy.
+ *
+ * Y aquí, además, cae en el sitio correcto por significado: la constante del
+ * gate es una lista de `NodeType`, y `NodeType` vive en este fichero de al
+ * lado. En cualquier otro paquete sería una lista de cadenas sueltas que nadie
+ * comprueba contra el catálogo de nodos.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.RESPUESTA_DEL_SYNC_POR_DEFECTO = exports.TOPE_DE_ESPERA_DEL_SYNC = exports.TOPES_DE_ESTADO = exports.SOBRES_DE_RESPUESTA = exports.MODOS_DE_PAYLOAD = exports.NIVELES_DE_DETALLE = exports.RESULTADOS_DEL_VALIDADOR = exports.NODOS_QUE_CONTESTAN_EN_SYNC = void 0;
+exports.contestaEnSync = contestaEnSync;
+exports.armarRespuestaDelSync = armarRespuestaDelSync;
+/* ── El gate ──────────────────────────────────────────────────────── */
+/**
+ * Los tipos de nodo que SABEN contestar en `sync`.
+ *
+ * Lo lee la api al guardar —para no dejar activar `responseMode: 'sync'` en un
+ * flujo que no lleva ninguno— y el dashboard para avisar antes de guardar.
+ *
+ * 🔥 Es una CONSTANTE y no el literal `'schemaValidator'` repartido por los dos
+ * sitios, y la razón no es estética: el día que un segundo nodo implemente
+ * `getSyncResult`, con literales el gate sigue compilando, sigue pasando los
+ * tests y **se queda mintiendo en silencio** —le dice al usuario que su flujo
+ * no puede contestar cuando sí puede—. Un fallo que no rompe nada es el que
+ * sobrevive años.
+ *
+ * ⚠️ Y lo que esta lista NO puede comprobar desde aquí: que sea la misma que
+ * la de los handlers que de verdad implementan `getSyncResult`. Esos viven en
+ * hw-nodes, que este paquete no ve ni debe ver. El guardián de esa atadura va
+ * ALLÍ, que es donde están los handlers — el mismo reparto que ya usa
+ * `pasaLoQueRecibe`: la tabla se fija aquí y
+ * `el-panel-lee-lo-mismo-que-el-handler.spec.ts` la ata en hw-nodes.
+ *
+ * ⚠️⚠️ Presencia no es paso. Que el flujo LLEVE un validador no garantiza que
+ * el evento pase por él: un conditional o un filter puede rutear alrededor. Por
+ * eso el gate es de producto y no de corrección, y por eso `'no-verdict'`
+ * existe ahí abajo — sin él, el flujo con el gate puesto se colgaría igual.
+ */
+exports.NODOS_QUE_CONTESTAN_EN_SYNC = [
+    'schemaValidator',
+];
+/**
+ * ¿Este tipo de nodo sabe contestar en `sync`?
+ *
+ * Acepta `string` y no `NodeType` a propósito: quien pregunta es la api con lo
+ * que trae un documento de mongo y el dashboard con lo que hay en el lienzo, y
+ * los dos manejan cadenas que todavía no han pasado por ningún tipo.
+ */
+function contestaEnSync(tipo) {
+    return exports.NODOS_QUE_CONTESTAN_EN_SYNC.includes(tipo);
+}
+/* ── Lo que el validador dictamina ────────────────────────────────── */
+/**
+ * Los cuatro finales posibles de una espera en `sync`. Son cuatro y no dos, y
+ * los dos de en medio son los que hoy faltan:
+ *
+ * - `valid` — el payload pasó. **Esto es lo que hoy no contesta nadie**: el
+ *   `getSyncResult` del validador devuelve `null` cuando todo está bien y el
+ *   paso 8.5 de `node-lifecycle.ts` sólo resuelve `if (syncResult)`. O sea que
+ *   el camino FELIZ es el que se cuelga 120 s y sale con un 408. Pasar la
+ *   validación era indistinguible de que no contestara nadie.
+ * - `invalid` — el payload no pasó. El único que funciona hoy.
+ * - `no-verdict` — la corrida TERMINÓ y ningún validador se pronunció (nadie
+ *   pasó por él, o el flujo no lleva ninguno). Hay que contestar igual, ahí
+ *   mismo, en vez de esperar el tope entero.
+ * - `timeout` — se acabó la espera de verdad.
+ */
+exports.RESULTADOS_DEL_VALIDADOR = [
+    'valid',
+    'invalid',
+    'no-verdict',
+    'timeout',
+];
+/* ── Cómo se quiere la respuesta ──────────────────────────────────── */
+/**
+ * Cuánto se le cuenta al cliente de POR QUÉ falló.
+ *
+ * Los valores van en inglés aunque el tipo se llame en español, por lo mismo
+ * que `FORMATOS_DEL_ESQUEMA`: acaban en un `enum` de mongoose, en un `@IsIn`
+ * de un DTO y en un `<select>`, y ninguno de esos tres sitios quiere una
+ * cadena en español dentro de un JSON que un cliente puede exportar.
+ *
+ * - `full` — ruta, regla y esperado. Lo que quiere quien integra con su propio
+ *   equipo detrás.
+ * - `fields-only` — QUÉ campos fallaron, sin el porqué. El término medio para
+ *   un formulario público: basta para señalar la casilla en rojo y no publica
+ *   las reglas.
+ * - `opaque` — «Invalid payload» y ya. **Ni una ruta de campo sale de aquí.**
+ *   Un esquema es un mapa de tu modelo de datos; repartirlo por un endpoint
+ *   público es regalar el trabajo de enumeración a quien lo quiera.
+ */
+exports.NIVELES_DE_DETALLE = ['full', 'fields-only', 'opaque'];
+/**
+ * Si se le devuelve al cliente lo que mandó, y cuánto.
+ *
+ * - `none` — no.
+ * - `full` — tal cual llegó. No revela nada: es SU payload.
+ * - `failed-fields` — sólo los campos que fallaron, **en plano**, con la ruta
+ *   completa como clave: `{ "user.email": "nope", "items[0].sku": 12 }`.
+ *   Plano y no reconstruido con su anidamiento por dos razones: reconstruirlo
+ *   añade una segunda lectura de rutas que puede discrepar de la del
+ *   validador, y porque quien está depurando quiere la lista de lo que falló
+ *   junto a lo que mandó, no un recorte del original con la misma forma.
+ */
+exports.MODOS_DE_PAYLOAD = ['none', 'full', 'failed-fields'];
+/**
+ * La forma del sobre.
+ *
+ * - `hostwebhook` — el nuestro, el que ya sale hoy por el cable.
+ * - `problem+json` — RFC 7807, con su `content-type: application/problem+json`.
+ *   Lo piden los que meten esto detrás de un cliente generado.
+ */
+exports.SOBRES_DE_RESPUESTA = ['hostwebhook', 'problem+json'];
+/**
+ * Los topes de los códigos de estado, exportados para que el dashboard ponga
+ * el `min`/`max` de cada caja desde AQUÍ y no a ojo.
+ *
+ * El del éxito acaba en 299 por lo que pidió el dueño: nada de un 500 en el
+ * éxito. Y no es una manía — un 5xx en la respuesta de «tu payload es válido»
+ * hace que el cliente reintente, y reintentar un webhook aceptado duplica el
+ * evento.
+ *
+ * El del error se queda en 4xx: la culpa del payload es de quien lo manda, y un
+ * 5xx ahí también invita al reintento de lo que nunca va a pasar.
+ *
+ * El del timeout llega hasta 599 porque ahí sí caben los dos: 408 (lo que sale
+ * hoy) y 504, que es lo que muchos proxies esperan.
+ */
+exports.TOPES_DE_ESTADO = {
+    success: { min: 200, max: 299, defecto: 200 },
+    error: { min: 400, max: 499, defecto: 422 },
+    timeout: { min: 400, max: 599, defecto: 408 },
+};
+/**
+ * Cuánto se puede tener la conexión viva.
+ *
+ * ⚠️ El `max` es `SYNC_TIMEOUT_SECONDS` de `@hostwebhook/node-sdk`
+ * (`topes/plan.constants.ts`), que es el `setTimeout` real del `waitForSync`
+ * del gateway. Está copiado y no importado porque este paquete **no tiene ni
+ * una dependencia** —es justo lo que lo hace servible en el navegador— y
+ * traerse node-sdk arrastraría mongoose, express y un binario nativo.
+ *
+ * Que la copia no se despiste lo ata un test EN node-sdk, que sí puede ver los
+ * dos: `el-tope-de-la-espera-es-uno.test.ts`. Sin esa atadura, configurar 200 s
+ * aquí daría una pantalla que promete 200 y un gateway que corta a los 120.
+ */
+exports.TOPE_DE_ESPERA_DEL_SYNC = {
+    min: 1,
+    max: 120,
+    defecto: 120,
+};
+/**
+ * Lo que se usa cuando no se configuró nada.
+ *
+ * Están elegidos para que un webhook que no toque nada se comporte IGUAL que
+ * antes de todo esto: 422 al fallar, 120 s de espera, 408 al agotarse, el sobre
+ * de siempre y sin devolver el payload. Lo único que cambia respecto a hoy es
+ * que el camino feliz ahora contesta en vez de colgarse, que era el bug.
+ *
+ * `detail: 'full'` por lo mismo: es lo que sale hoy por el cable.
+ */
+exports.RESPUESTA_DEL_SYNC_POR_DEFECTO = {
+    successStatus: exports.TOPES_DE_ESTADO.success.defecto,
+    errorStatus: exports.TOPES_DE_ESTADO.error.defecto,
+    detail: 'full',
+    includePayload: 'none',
+    envelope: 'hostwebhook',
+    problemType: 'about:blank',
+    timeoutSeconds: exports.TOPE_DE_ESPERA_DEL_SYNC.defecto,
+    timeoutStatus: exports.TOPES_DE_ESTADO.timeout.defecto,
+};
+/* ── La función ───────────────────────────────────────────────────── */
+const TIPO_JSON = 'application/json; charset=utf-8';
+const TIPO_PROBLEMA = 'application/problem+json; charset=utf-8';
+/**
+ * Los huecos que la plantilla sabe rellenar. Cerrado a propósito: un hueco que
+ * no esté en esta lista se queda ESCRITO en la salida en vez de borrarse.
+ *
+ * Que parece lo feo, y es lo correcto: la plantilla la escribe el usuario en su
+ * propia caja, con la vista previa al lado. Un `{{fied}}` mal tecleado que se
+ * borra en silencio es un mensaje al que le falta un trozo y nadie sabe por
+ * qué; uno que se queda escrito se ve en la previa antes de guardar.
+ */
+const HUECO = /\{\{\s*(field|rule|expected)\s*\}\}/g;
+function rellenarPlantilla(plantilla, fallo) {
+    /* ⚠️ Con FUNCIÓN de reemplazo, no con cadena. Con cadena, un `$&` o un `$1`
+       dentro de una ruta de campo —que viene del payload de un desconocido— lo
+       interpretaría `String.replace` y saldría otra cosa por el cable. Con
+       función, lo que se devuelve se inserta literal. */
+    return plantilla.replace(HUECO, (_todo, hueco) => {
+        if (hueco === 'field')
+            return fallo.path;
+        if (hueco === 'rule')
+            return fallo.rule ?? '';
+        return fallo.expected ?? '';
+    });
+}
+/** El texto final de un fallo: override de campo, plantilla general, o el original. */
+function mensajeDelFallo(fallo, config) {
+    const propia = config.fieldTemplates?.[fallo.path];
+    if (propia !== undefined)
+        return rellenarPlantilla(propia, fallo);
+    if (config.messageTemplate !== undefined) {
+        return rellenarPlantilla(config.messageTemplate, fallo);
+    }
+    return fallo.message;
+}
+function enRango(valor, tope) {
+    /* No lanza y no recorta al borde: vuelve al defecto. Lanzar dejaría la vista
+       previa en blanco justo cuando hace falta, y recortar (un 500 que se queda
+       en 299) inventa un número que nadie escribió. Volver al defecto se VE en la
+       previa —pusiste 500 y la previa dice 200—, que es el aviso que hace falta. */
+    if (typeof valor !== 'number' || !Number.isInteger(valor))
+        return tope.defecto;
+    return valor >= tope.min && valor <= tope.max ? valor : tope.defecto;
+}
+/**
+ * Lee el valor que hay en `payload` en la ruta `user.email` o `items[0].sku`.
+ *
+ * Misma partición que `getNestedValue` de `schema-validator-utils.ts`: las
+ * rutas las escribe el mismo panel, así que leerlas de otra manera aquí haría
+ * que `failed-fields` devolviera `undefined` justo en las rutas con corchetes.
+ */
+function valorEnLaRuta(payload, ruta) {
+    const segmentos = ruta
+        .split(/\.|\[(\d+)\]/)
+        .filter((s) => s !== '' && s !== undefined);
+    return segmentos.reduce((actual, clave) => {
+        if (actual === null || actual === undefined)
+            return undefined;
+        if (Array.isArray(actual) && /^\d+$/.test(clave))
+            return actual[Number(clave)];
+        if (typeof actual === 'object') {
+            return actual[clave];
+        }
+        return undefined;
+    }, payload);
+}
+/**
+ * Arma la respuesta que recibe quien llamó en `sync`.
+ *
+ * PURA: sin nestjs, sin mongoose, sin `Date.now()`, sin nada de servidor. Entra
+ * un veredicto y una configuración, sale la respuesta. Por eso puede correr
+ * igual en el handler de hw-nodes y en el navegador del dashboard, y por eso la
+ * vista previa no puede desincronizarse: es literalmente la misma llamada.
+ */
+function armarRespuestaDelSync(veredicto, config = {}) {
+    const sobre = config.envelope ?? exports.RESPUESTA_DEL_SYNC_POR_DEFECTO.envelope;
+    const detalle = config.detail ?? exports.RESPUESTA_DEL_SYNC_POR_DEFECTO.detail;
+    /* ── Éxito ─────────────────────────────────────────────────────────
+       El sobre NO se aplica aquí, y es una decisión: RFC 7807 describe
+       PROBLEMAS. Un 200 con `application/problem+json` es un uso equivocado del
+       tipo, y el cliente generado que lo lea buscará un `title` que no existe. */
+    if (veredicto.outcome === 'valid' || veredicto.outcome === 'no-verdict') {
+        const body = { accepted: true };
+        if (veredicto.eventId !== undefined)
+            body.eventId = veredicto.eventId;
+        /* 🔥 `validated: false` SÓLO cuando nadie se pronunció. El bug que esto
+           viene a arreglar era precisamente que pasar la validación y que no
+           contestara nadie salían iguales; sería absurdo volver a juntarlos aquí,
+           un escalón más arriba. Con validador de por medio el cuerpo es el que
+           pidió el dueño, `{accepted, eventId}` y nada más. */
+        if (veredicto.outcome === 'no-verdict')
+            body.validated = false;
+        return {
+            status: enRango(config.successStatus, exports.TOPES_DE_ESTADO.success),
+            headers: { 'content-type': TIPO_JSON },
+            body,
+        };
+    }
+    /* ── Timeout ───────────────────────────────────────────────────── */
+    if (veredicto.outcome === 'timeout') {
+        const status = enRango(config.timeoutStatus, exports.TOPES_DE_ESTADO.timeout);
+        if (config.timeoutBody !== undefined) {
+            return {
+                status,
+                headers: {
+                    'content-type': sobre === 'problem+json' ? TIPO_PROBLEMA : TIPO_JSON,
+                },
+                body: { ...config.timeoutBody },
+            };
+        }
+        if (sobre === 'problem+json') {
+            const body = {
+                type: config.problemType ?? exports.RESPUESTA_DEL_SYNC_POR_DEFECTO.problemType,
+                title: 'Pipeline timeout',
+                status,
+            };
+            if (veredicto.eventId !== undefined) {
+                body.instance = `/events/${veredicto.eventId}`;
+            }
+            return { status, headers: { 'content-type': TIPO_PROBLEMA }, body };
+        }
+        /* El cuerpo de hoy, letra por letra. */
+        const body = { error: 'Pipeline timeout' };
+        if (veredicto.eventId !== undefined)
+            body.eventId = veredicto.eventId;
+        return { status, headers: { 'content-type': TIPO_JSON }, body };
+    }
+    /* ── Inválido ──────────────────────────────────────────────────── */
+    const status = enRango(config.errorStatus, exports.TOPES_DE_ESTADO.error);
+    const opaco = detalle === 'opaque';
+    /* 🔥 `failed-fields` se degrada a `none` cuando el detalle es `opaque`, y
+       esto es LA línea de seguridad de todo el fichero. Las CLAVES de ese objeto
+       son las rutas de los campos que fallaron: devolverlo es dar exactamente la
+       misma información que `fields-only`, sólo que por otra puerta. Un usuario
+       que elige `opaque` y deja el payload puesto no está pidiendo eso; está
+       pidiendo no filtrar.
+  
+       `full` sí sigue permitido con `opaque`, y la razón es que NO PUEDE filtrar:
+       devuelve exactamente lo que entró, así que jamás contiene un nombre de
+       campo que quien llama no hubiera escrito él mismo. Quien intenta enumerar
+       el esquema manda `{"probe":1}` y le vuelve `{"probe":1}`. Degradarlo «por
+       si acaso» le quitaría a un usuario legítimo el poder ver su propia petición
+       en sus logs, a cambio de cero seguridad. */
+    const modoPayload = config.includePayload ??
+        exports.RESPUESTA_DEL_SYNC_POR_DEFECTO.includePayload;
+    const payloadDevuelto = opaco && modoPayload === 'failed-fields' ? 'none' : modoPayload;
+    let payload;
+    if (payloadDevuelto === 'full') {
+        payload = veredicto.payload;
+    }
+    else if (payloadDevuelto === 'failed-fields') {
+        const recorte = {};
+        for (const fallo of veredicto.errors) {
+            recorte[fallo.path] = valorEnLaRuta(veredicto.payload, fallo.path);
+        }
+        payload = recorte;
+    }
+    const hayPayload = payloadDevuelto !== 'none' && payload !== undefined;
+    /* Los errores, según el nivel. `opaque` no llega aquí: se queda sin array. */
+    const errores = opaco
+        ? []
+        : veredicto.errors.map((fallo) => {
+            if (detalle === 'fields-only') {
+                /* Qué campos, sin el porqué. Ni `message`, ni `rule`, ni `expected`:
+                   un `expected: "^EMP-\\d{6}$"` cuenta el formato entero de un id
+                   interno, que es justo lo que este nivel viene a callar. */
+                return { path: fallo.path };
+            }
+            const salida = { path: fallo.path };
+            if (fallo.rule !== undefined)
+                salida.rule = fallo.rule;
+            if (fallo.expected !== undefined)
+                salida.expected = fallo.expected;
+            salida.message = mensajeDelFallo(fallo, config);
+            return salida;
+        });
+    if (sobre === 'problem+json') {
+        const body = {
+            type: config.problemType ?? exports.RESPUESTA_DEL_SYNC_POR_DEFECTO.problemType,
+            title: opaco ? 'Invalid payload' : 'Schema Validation Failed',
+            status,
+        };
+        /* ⚠️ Ni `detail` ni un recuento con `opaque`. «3 fields failed» no dice
+           cuáles, pero sí dice cuántos campos tiene el esquema por lo bajo y
+           cuántos acertó quien está probando: es una señal de enumeración, que es
+           exactamente lo que este nivel corta. El dueño lo dijo así: «Invalid
+           payload» y ya. */
+        if (!opaco) {
+            const n = errores.length;
+            body.detail = `${n} field${n === 1 ? '' : 's'} failed validation`;
+        }
+        if (veredicto.eventId !== undefined) {
+            body.instance = `/events/${veredicto.eventId}`;
+        }
+        /* `errors` y `payload` son miembros de EXTENSIÓN del 7807, que el RFC
+           permite explícitamente. No se meten dentro de `detail` porque `detail`
+           es texto para un humano y esto es para una máquina. */
+        if (!opaco)
+            body.errors = errores;
+        if (hayPayload)
+            body.payload = payload;
+        return { status, headers: { 'content-type': TIPO_PROBLEMA }, body };
+    }
+    /* El sobre de siempre. El orden de las claves es el del 422 que ya sale hoy
+       por el cable, para que quien lo esté leyendo con un diff no vea ruido. */
+    const body = {
+        error: opaco ? 'Invalid payload' : 'Schema Validation Failed',
+    };
+    /* `eventId` va en TODOS los cuerpos cuando se conoce, y en `opaque` es lo que
+       hace que el nivel sea usable: el cliente no se entera de nada del esquema,
+       pero trae un identificador con el que tú sí puedes buscar la corrida cuando
+       te escriba. Opaco para fuera, trazable para dentro. */
+    if (veredicto.eventId !== undefined)
+        body.eventId = veredicto.eventId;
+    if (!opaco) {
+        if (veredicto.webhookName !== undefined) {
+            body.webhookName = veredicto.webhookName;
+        }
+        if (veredicto.nodeName !== undefined)
+            body.nodeName = veredicto.nodeName;
+        /* `message` como array de `ruta: texto` es lo que se manda hoy. Con
+           `fields-only` no hay texto que juntar, así que se queda sólo la ruta —y
+           no se omite el campo entero, porque quien lo lee hoy espera un array. */
+        body.message = veredicto.errors.map((fallo) => detalle === 'fields-only'
+            ? fallo.path
+            : `${fallo.path}: ${mensajeDelFallo(fallo, config)}`);
+        body.errors = errores;
+    }
+    if (hayPayload)
+        body.payload = payload;
+    return { status, headers: { 'content-type': TIPO_JSON }, body };
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hostwebhook/node-types",
-  "version": "1.77.0",
+  "version": "1.79.0",
   "description": "Shared node type definitions, connection rules, and dispatch config for HostWebhook",
   "main": "dist/index.js",
   "module": "dist/esm/index.js",