bug: RBAC loader logs "plugin found but failed to load" when @triggerdotdev/plugins is simply not installed
Maintainer antworten meist innerhalb von 1 Tag
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 82/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- typescript
- Bereich
- authorization
Rechercherichtung
Beginne in internal-packages/rbac/src/index.ts um die Zeilen 167-209, wo die ERR_MODULE_NOT_FOUND-Meldung mit @triggerdotdev/plugins/rbac verglichen wird, um zu entscheiden, ob das Plugin selbst fehlt. Reproduziere die Form der Meldung, indem du in Node einen dynamischen Import eines nicht installierten Pakets versuchst, und erweitere dann die Prüfung auf fehlendes Plugin so, dass sie auch den in Anführungszeichen gesetzten Paketnamen abgleicht, während ein defektes installiertes Plugin weiterhin deutlich gemeldet wird. Wende dieselbe Änderung auf die Loader in internal-packages/sso/src/index.ts (Zeilen 60-93) und internal-packages/billing/src/index.ts (Zeile 78) an; fertig, wenn alle drei bei einem fehlenden Paket still bleiben, aber bei einem vorhandenen, aber defekten weiterhin den Fehler protokollieren.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 16.5k
- Forks
- 1.5k
- Ø Merge
- 1 T. 15 Std.
- Gemergte PRs (30 T.)
- 17
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus triggerdotdev/trigger.dev
-
bug: retry.fetch ignores the caller's abort signal and retries aborted requestsEvtl. wieder frei Ein Pull Request dazu wurde ohne Merge geschlossen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
triggerdotdev/trigger.dev#5116 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug: Chat transport crashes on Safari < 17.4: AbortSignal.any is not a functionEvtl. wieder frei Ein Pull Request dazu wurde ohne Merge geschlossen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
triggerdotdev/trigger.dev#5098 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug: Side menu items lose their active state on detail pagesEvtl. wieder frei Ein Pull Request dazu wurde ohne Merge geschlossen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
triggerdotdev/trigger.dev#5088 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
triggerdotdev/trigger.dev#5072 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
triggerdotdev/trigger.dev#5067 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in triggerdotdev/trigger.dev
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
bug platform-android
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Termix-SSH/Mobile#146 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
devswha/herdr-web-ui#3875 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 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
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag