Inspect loaded plugins

The console's Plugins page (/plugins, apps/config-plane/app/plugins/PluginsView.tsx) shows the plugins the API process loaded at boot, whatever their origin: a PLUGINS_PATH folder, a registry download or a path: override. Use it to check that a plugin is loaded in the expected version, to find the bindings to activate on an instance, to read the contract of a declared event, or to see which triggers claim an event type. The page is read-only and everything it shows is read from the loaded manifests: an event, a binding or a protocol appears there because a loaded plugin.yaml declares it.

The page does not show which workflows start on an event. That is the Routing screen (« Routage », /routing), block Workflows started, by event type (« Workflows démarrés, par type d'événement »); see Choose which events start a workflow.

Prerequisites

• A running instance with the console open — see First instance.
• The plugins installed — see Declare and install plugins.

Open a plugin

1. Open Plugins in the left rail. The list shows each loaded plugin with its version and its number of events and contributions; the filter matches the name and the description.
2. Select a plugin. Its header shows the SDK range, the source language, the translations (the i18n/<locale>.yaml overlays other than the source language), the dependencies (a dependency that is not loaded is marked not loaded), the loaded plugins that depend on it, and the directory it was loaded from.

The page state is kept in the URL, so each view is a link you can share: /plugins?plugin=<name> opens a plugin, &tab=contributions or &tab=manifest picks a tab. A link inside the page opens its target row, scrolls to it and marks it.

Read the Events tab

A contract is open. The Declared event section of the trigger inspector ends with the note Undeclared fields are accepted and passed on as received. (« Les champs non déclarés sont acceptés et transmis tels quels. »). POST /api/events checks the declared fields against the contract according to the instance's EVENT_CONTRACTS mode; undeclared fields are not checked (see Event ingestion API).

The example shown is the one the manifest declares. When the host found it non-conforming at load, it removed it from the event registry: the Emit an event composer, the filter's Example event and simulation then use an example without it, built from the event's required context kinds only, while this page shows the manifest's text. The log line « exemple d'événement retiré » names the event.

The default filter shown is the one the manifest declares. When the host found it invalid at load, it removed it from the event: the creation dialog no longer pre-fills it and publication no longer warns about it, while this page shows the manifest's text. The log line « événement signalé » names the event. The default filter is a proposal to the workflows that receive the event; it never filters an event by itself.

Claims and producers are computed over the loaded plugins only. An event with no loaded producer can still be posted to POST /api/events. A declared event is also received by the core trigger Événement reçu (trigger.event-received), configured on it in a workflow: an event whose Dedicated triggers row reads none loaded (« aucun chargé ») is still accepted and starts the workflows configured on it. The host's own transports are added to those a plugin declares. The Claimed by column (« Revendiqué par ») of the produced events and of the event catalogue lists the triggers of loaded plugins that claim the type, then the core triggers that receive it — Événement reçu for every declared event —; it reads no loaded trigger (« aucun déclencheur chargé ») only for a type no loaded plugin declares and no trigger claims. A trigger with its own address (pinnedRouting) is marked pinned routing: the host refuses a declaration whose type is such an address. A trigger without pinnedRouting and without event claims nothing.

A contribution the manifest declares but the host dropped at load is still listed, marked ignored at load: a declared event whose declaration is invalid, whose type another plugin already declares or whose type is the address of a pinned trigger, a node whose types or context kinds are unknown (or whose event cannot be resolved, a trigger without pinnedRouting and without event, a node that carries receive without being a pinned trigger, or a node whose behavior module does not import), a reception whose module is invalid or does not import, or whose protocol another plugin already contributes, a message binding whose module does not import or whose protocol is not received, and a message or source binding whose event no loaded trigger without its own address receives: a type that no loaded plugin declares, claimed by no trigger or only by pinned triggers such as the reception of a raw message. Such a binding is logged with its cause, « binding ignoré : événement « » non déclaré par les plugins chargés. Charger le plugin qui le déclare. » or « binding ignoré : « » est l'adresse du déclencheur épinglé « ». Viser un événement déclaré. »; a dropped source binding's feed never starts, and an inbound connection that names it is unusable (Binding inconnu pour ce protocole : <name>.). The API log gives the reason. The catalogue counters only count what the host kept.

Some load problems drop nothing, so the page does not mark them: a binding that does not match its event's contract (« binding hors contrat »), a key the manifest schema does not know, which is ignored and named by its path (« clé ignorée »; the Manifest tab still shows it in the text), a defaultSelector on a node, which is ignored (« déclencheur signalé » on a trigger, « nœud signalé » on another node), the address of a pinned trigger that another plugin declares as an event, refused (« déclencheur signalé »), an invalid default filter removed from its event (« événement signalé »), an sdk range below the one the manifest needs (« plage sdk insuffisante »), a removed example (« exemple d'événement retiré ») and, at info, a default filter that reads a field outside its event's contract (« filtre par défaut hors contrat »). An adapter, an event source or a port sandbox whose module does not import is not loaded, and a node whose assistance module does not import loads without configuration assistance; the page does not mark them either (« module non chargé », which names the module and the contribution). They appear only in the API log, component plugins; each warning, with its fields and effect, is listed in Observability signals — plugin load warnings.

Read the Contributions tab

One section per contribution kind: nodes (label, description, config fields, ports, the fields that set them apart: event or eventType, receive, context, establishes, dynamic, derivedPorts, assist, agentTool, the example payload of a trigger, the hints and example of a configuration assistant, modules), types, value sets, dimensions, context kinds, conversions, agents (ports, tools, prompt, API exposure with its authentication and credential id), adapters and port sandboxes.

A trigger with receive shows the reception its manifest describes (Reception / « Réception »): the protocol's own transports, each with its proposed port and its hint (the text the connection form shows), the media types of an HTTP connection when the manifest declares them, and the example message.

A trigger with event links to the declaration of its event, in the Events tab of the plugin that declares it (or states that no loaded plugin declares it). The context kinds it establishes are the event's. When the event declares a default filter, the trigger shows it under that link (Default filter / « Filtre par défaut »), as the declaration writes it: it is the filter proposed to a workflow that starts from this trigger. Its outputs show the contract key each one reads (from) when it differs from the output name; when the manifest omits the outputs of a trigger without behavior, the outputs listed are the event's fields. The example payload shown is the event's.

A node with derivedPorts lists its port rules: one port per entry of a config list or a single port, and for the name, type, required flag and description, either a literal value or the key it is read from, in the current entry (from) or in the node config (fromConfig), with its default. Labels and descriptions follow the console language when the plugin ships a translation for it.

Read the raw manifest

The Manifest tab shows the plugin.yaml text as the API read it at load: source language, comments and anchors kept, coloured as YAML. It is fetched when the tab is first opened.

• Copy puts the text on the clipboard. When the clipboard is refused or unavailable (page not served over HTTPS), the text is selected and copied through the browser; if that fails too, it stays selected for a keyboard copy.
• Download saves it under a name derived from the plugin name, for example acme-vitals.plugin.yaml for @acme/vitals.

The text is kept while the page is open. Opening the page again reloads the plugin list and fetches the manifest again, so a restarted API shows its new text.

Use the event catalogue

Event catalogue, at the top of the plugin list, lists every event type that a loaded plugin declares (contributes.events), that a trigger claims or that a reception or binding produces, with the plugin that declares it, its producers and the triggers that claim it. Below the introduction, the line « Tout événement déclaré peut aussi être reçu par : … » (« Any declared event can also be received by: … ») names the core triggers that receive any declared event, Événement reçu; the triggers listed per event are the triggers of plugins that claim it, then Événement reçu when the event is declared. The counters give the events without a declaration and without a producer. An event that only triggers with their own address claim (the raw message of a reception, such as HL7v2Received) is not counted without a declaration: event does not apply to a trigger with pinnedRouting. /plugins?view=catalogue&event=<type> marks one event.

Query the API directly

The page reads two API routes (apps/api/src/server/plugin-reference.ts):

• GET /api/plugins?locale=<l> — the parsed manifest of each loaded plugin, localized, with its dir, locales (the overlay locales) and active: the node ids registered in the catalog (nodes), the triggers whose reception is active (receptions), the active message bindings (messageBindings), the source bindings the host kept (eventBindings; the inbound connections of each source enable them) and the declared events registered under the plugin's name (events).

• GET /api/plugins/<name>/manifest — the raw plugin.yaml of a loaded plugin, as text/yaml:

  curl -s http://localhost:4000/api/plugins/@acme/vitals/manifest
  

  The text is the one kept in memory at load; nothing is read from disk at request time. A name that no loaded plugin carries returns 404.

The trigger inspector and the editor read the event registry through another route:

• GET /api/catalog?locale=<l> — the node catalogue, with eventTypes: each declared event the host kept, localized, with its example as registered (without an example the host removed):

  curl -s 'http://localhost:4000/api/catalog?locale=en' | jq '.eventTypes'
  

Related

• Declare and install plugins — load a plugin on the instance.
• Connect an event source — enable the bindings listed here on a connection of their source.
• Plugin manifest — the fields each section reads.
• The open event model — producers, triggers and bindings.