bug: RBAC loader logs "plugin found but failed to load" when @triggerdotdev/plugins is simply not installed

Abierto Apto para principiantes
#5,083 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@itsfaryal ya está trabajando en esto.

Desde el 28/10/2026.

  • #5102 de @cocvn157 — cerrado sin fusionar

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
82/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript

Línea de trabajo

Empieza en internal-packages/rbac/src/index.ts alrededor de las líneas 167-209, donde el mensaje ERR_MODULE_NOT_FOUND se compara con @triggerdotdev/plugins/rbac para decidir si falta el propio plugin. Reproduce la forma del mensaje intentando una importación dinámica de un paquete no instalado en Node, y luego amplía la comprobación de plugin faltante para que también coincida con el nombre del paquete entre comillas, manteniendo ruidoso un plugin instalado roto. Aplica el mismo cambio a los loaders en internal-packages/sso/src/index.ts (líneas 60-93) e internal-packages/billing/src/index.ts (línea 78); terminado cuando los tres permanezcan silenciosos para un paquete ausente pero sigan registrando el error para uno presente pero roto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Provide environment information

Self-hosted, official Helm chart 4.8.1 (image ghcr.io/triggerdotdev/trigger.dev:v4.8.1) on Kubernetes 1.35. The plugins package is not installed, which is the normal state for a self-hosted install. REQUIRE_PLUGINS and RBAC_LOG_FALLBACK are not set.

Describe the bug

On every webapp boot a self-hosted instance logs this at error level:

RBAC: plugin found but failed to load; falling back to default implementation Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@triggerdotdev/plugins' imported from /triggerdotdev/apps/webapp/build/server/assets/server-build-<hash>.js

The plugin was not found, it is simply not installed. Per the comments in the loader, that case should be silent unless RBAC_LOG_FALLBACK=1, and the "found but failed to load" error is meant only for a plugin that is present but broken.

The cause is the check that tells the two cases apart (rbac/src/index.ts#L167-L209):

const moduleName = "@triggerdotdev/plugins/rbac";
// ...
const isPluginItselfMissing = isModuleNotFound && message.includes(moduleName);

When the whole package is absent, Node's error names only the package, not the subpath: Cannot find package '@triggerdotdev/plugins'. So message.includes("@triggerdotdev/plugins/rbac") is false, and the missing plugin is classified as a broken one.

The SSO and billing loaders use the same check (sso/src/index.ts#L60-L93, billing/src/index.ts#L78). We only saw the RBAC line, presumably because those load lazily. The code is unchanged on main.

Expected: no error log when @triggerdotdev/plugins is not installed.

Reproduction repo

N/A: reproduces with the official chart/image; code links above.

To reproduce
  1. Install or upgrade the official Helm chart 4.8.1 (any self-hosted install without @triggerdotdev/plugins).
  2. kubectl -n <ns> logs deploy/<release>-webapp -c webapp | grep RBAC
  3. See the "plugin found but failed to load" error on each boot.
Suggested fix

Also accept the quoted package name when deciding whether the plugin itself is missing, e.g.

const isPluginItselfMissing =
  isModuleNotFound &&
  (message.includes(moduleName) || message.includes("'@triggerdotdev/plugins'"));

and the same in the SSO and billing loaders. Matching the quoted name, not the bare one, keeps a broken plugin loud: if an installed plugin's own dependency is missing, the message quotes that dependency's name, and @triggerdotdev/plugins appears only unquoted in the imported from path.

Additional information

Harmless at runtime (the fallback is the documented self-hosted behaviour), but an error-level line on every boot sends self-hosters looking for a broken install.

Lenguaje dominante
TypeScript
Estrellas
16.5k
Forks
1.5k
Merge medio
1 d 15 h
PR fusionados (30 d)
17

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de triggerdotdev/trigger.dev

Todos los issues de triggerdotdev/trigger.dev

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.