Say what a plugin settings tab can actually do, and catch a declaration that cannot work
Finding F12 of the architectural review, checked against the code and found worse than reported: the dynamic component import cannot be rewritten by the bundler, so the built file ships the unresolved path and a plugin tab answers 404 in every production build, staged or not. It works only under the dev server. Nothing shipping is affected, because the one plugin that declares a tab also registers the same page as an ordinary route, and that is the one sites reach. - The ADR draft now carries a "Constraints as implemented" section: only the model catalog hub registers plugin tabs, registration happens when that hub mounts so a tab is not deep-linkable and does not survive a refresh, and the build finding above with the bundler's own warning. The two ways out are stated as the open decision rather than taken. - The hook's docstring reads as instructions to a plugin author, and its example no longer names a path that does not exist at build time. - A route declared for a hub that cannot render it is dropped with an error naming the plugin, the hub and the hubs that do work, and the same is logged at startup. Enabling the plugin still succeeds: a tab nobody can reach is no reason to take a working backend offline. - Tests hold the two halves together: no bundled plugin may declare a hub the frontend does not implement, and the list in the server must equal the hubs that really register routes, so the two cannot drift apart again.
This commit is contained in:
@@ -6,7 +6,7 @@ from flask import Flask
|
||||
import logging
|
||||
import re
|
||||
|
||||
from .base import BasePlugin, PluginMeta
|
||||
from .base import BasePlugin, PluginMeta, renderable_settings_routes
|
||||
from .registry import PluginRegistry, PluginState
|
||||
from .loader import PluginLoader
|
||||
from .migrations import PluginMigrationManager
|
||||
@@ -103,6 +103,22 @@ class PluginManager:
|
||||
|
||||
for name, plugin in plugins.items():
|
||||
self._register_plugin_components(plugin)
|
||||
self._check_settings_routes(name, plugin)
|
||||
|
||||
def _check_settings_routes(self, name: str, plugin: BasePlugin) -> None:
|
||||
"""Say at boot, once per plugin, if a declared settings tab is dead.
|
||||
|
||||
Only some settings hubs draw plugin tabs (see
|
||||
SETTINGS_HUBS_WITH_PLUGIN_TABS). A route for any other hub is accepted
|
||||
by the hook and returned by the API and then rendered by nobody, which
|
||||
looks from every side like the plugin is at fault. The API drops such a
|
||||
route; this makes the same finding at startup, so it is in the log of a
|
||||
site that never opens the settings page."""
|
||||
try:
|
||||
renderable_settings_routes(name, plugin.get_settings_routes(),
|
||||
logger)
|
||||
except Exception:
|
||||
logger.exception("get_settings_routes failed for %s", name)
|
||||
|
||||
def upgrade_all_plugins(self) -> Dict[str, str]:
|
||||
"""Run pending Alembic migrations for every discovered plugin.
|
||||
|
||||
Reference in New Issue
Block a user