dsh-fal-image-gen 0.5.1

The plugin's card was sometimes missing from Settings → Plugins → Plugin configuration entirely, and stayed missing until the page was reloaded.

Why

The browser keeps one mirror of the Host settings document, and every settings surface — this card and the core ones alike — derives from it. It refreshes on exactly two signals, a document commit and a (re)connect. A namespace registering is neither: settings.register adds the registration to the registry and never emits settings/document-updated, which only a value change or a commit does.

The Host, meanwhile, answers HTTP well before registration finishes — on one harness the port was announced 1.4 seconds after start. A page that reads settings.describe inside that window gets a view without the namespaces that have not registered yet, and then never re-reads it. Nothing in the tab can recover: the card is not mounted there, so it cannot fix itself the way a mounted component could.

What changed

The client half asks the mirror to re-read while its namespace is absent from it — once a second, at most fifteen times. The mirror is shared, so one re-read brings back every other card too, including the core ones. In the healthy case this costs nothing measurable: the first check sees the namespace and no timer is ever started.

Verified on a staging harness. With the namespace present the check is a no-op and the card renders as before. With registration disabled in the installed host copy, the retry ran for twenty seconds with zero page errors, the core cards stayed intact, and the card was correctly absent — the Host really does not have that namespace, and the plugin does not pretend otherwise.

The real fix belongs upstream: either open the port after registration finishes, or invalidate the mirror when a namespace registers.

Install

dsh plugin --profile web add @goodandready/dsh-fal-image-gen