Local engine discovery permanently caches transient 500 ms timeout and routes plugins to cloud #396

Summary

Local data-engine discovery uses a fixed 500 ms timeout and permanently caches the first failed probe for the browser session. On a valid self-hosted LAN deployment, a slightly slow manifest response therefore makes WorldWideView silently route plugins to their declared cloud engine instead of the configured local engine.

The resulting plugin error is misleading. For example, the Aviation layer reported:

[Aviation] Data Engine API returned 404

even though the local /manifest included aviation and local /api/aviation returned HTTP 200.

This is distinct from the missing stock Aviation seeder reported in silvertakana/wwv-data-engine#25. It also affects any locally available plugin whenever the initial manifest probe takes longer than 500 ms.

Cause

src/core/data/engineManifest.ts:

1. aborts local /manifest discovery after 500 ms;
2. sets manifestFetched = true before the request;
3. leaves that flag set when the request times out or fails;
4. consequently prevents all later discovery attempts in the same page session.

Because resolveEngineUrl() then considers the plugin unavailable locally, its resolution order selects the plugin's getServerConfig().streamUrl. For Aviation this was wss://dataenginev2.worldwideview.dev/stream, and its initial REST fetch reached the cloud API rather than the healthy local endpoint.

Reproduction

1. Run WWV and the data engine on a self-hosted machine accessible through a LAN hostname, such as http://host.local:3000 and http://host.local:5000.
2. Ensure /manifest lists a plugin and /api/<plugin> returns HTTP 200.
3. Add more than 500 ms latency to the first browser request to port 5000, or reproduce on a moderately loaded Wi-Fi/Raspberry Pi deployment.
4. Load WWV and enable that plugin.
5. Observe [EngineManifest] No local engine detected, using cloud.
6. Observe that DataBusSubscriber resolves the plugin to its cloud streamUrl.
7. Later local-engine recovery or successful responses do not help until the page is reloaded, because the failure is cached.

Expected behavior

• Normal LAN latency or a cold engine should not permanently disable local routing.
• Transient discovery failures should be retried on a later plugin activation.
• Once the manifest is retrieved successfully, successful discovery may remain cached.

Proposed patch

Tested fix: alexl83@2ce24c60

The patch:

• raises the discovery timeout from 500 ms to 3 seconds;
• retains caching for successful manifest responses;
• clears manifestFetched on HTTP errors, timeouts and connection failures;
• adds a regression test proving that a failed first probe can recover on the next call.

After deploying the ARM64 build, the same browser path logged:

[EngineManifest] Local engine detected: 20 seeders

and the Aviation plugin was resolved against the local engine instead of the cloud fallback.

Environment tested

• WorldWideView local edition
• Docker Compose on Linux ARM64 / Raspberry Pi 5
• Browser accessing WWV and the data engine over .local LAN hostname
• Data engine endpoint independently verified healthy and returning HTTP 200