bug: RBAC loader logs "plugin found but failed to load" when @triggerdotdev/plugins is simply not installed
Les mainteneurs répondent en général sous 1 jour
Évaluation
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 82/100
- Type d'issue
- Bug
- Clarté
- Clairement spécifiée
- Activité
- Active
- Stack technique
- typescript
- Domaine
- authorization
Piste de recherche
Commence à internal-packages/rbac/src/index.ts vers les lignes 167-209, où le message ERR_MODULE_NOT_FOUND est comparé à @triggerdotdev/plugins/rbac pour déterminer si le plugin lui-même est absent. Reproduis la forme du message en tentant un import dynamique d’un paquet non installé dans Node, puis élargis la vérification de plugin manquant pour qu’elle corresponde aussi au nom de paquet entre guillemets, en gardant bruyant un plugin installé cassé. Applique le même changement aux loaders dans internal-packages/sso/src/index.ts (lignes 60-93) et internal-packages/billing/src/index.ts (ligne 78) ; terminé lorsque les trois restent silencieux pour un paquet absent mais journalisent toujours l’erreur pour un paquet présent mais cassé.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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
- Install or upgrade the official Helm chart 4.8.1 (any self-hosted install without
@triggerdotdev/plugins). kubectl -n <ns> logs deploy/<release>-webapp -c webapp | grep RBAC- 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.
- Langage dominant
- TypeScript
- Étoiles
- 16.5k
- Forks
- 1.5k
- Merge moyen
- 1 j 15 h
- PR mergées (30 j)
- 17
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de triggerdotdev/trigger.dev
-
bug: retry.fetch ignores the caller's abort signal and retries aborted requestsPeut-être à nouveau libre Une pull request pour cette issue a été fermée sans être fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
triggerdotdev/trigger.dev#5116 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
bug: Chat transport crashes on Safari < 17.4: AbortSignal.any is not a functionPeut-être à nouveau libre Une pull request pour cette issue a été fermée sans être fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 83/100
triggerdotdev/trigger.dev#5098 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
bug: Side menu items lose their active state on detail pagesPeut-être à nouveau libre Une pull request pour cette issue a été fermée sans être fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
triggerdotdev/trigger.dev#5088 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 83/100
triggerdotdev/trigger.dev#5072 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
triggerdotdev/trigger.dev#5067 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de triggerdotdev/trigger.dev
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
bug platform-android
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Termix-SSH/Mobile#146 · 1 commentaire ·
Les mainteneurs répondent en général sous 2 jours
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
devswha/herdr-web-ui#3875 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
-
area: runtime chore cli consistency dependencies developer-experience difficulty: easy discovery documentation enhancement good first issue help wanted hygiene json-output packaging priority: P3 tests version
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour