api_v3: /health and /display/current read never-assigned module globals — health is permanently "degraded", display/current reports 128x64 on every rig

[ChuckBuilds]

Summary

web_interface/blueprints/api_v3.py declares module-level config_manager = None and plugin_manager = None (lines 81-82). Nothing ever assigns them — app.py:167 sets the blueprint attributes (api_v3.config_manager = config_manager), which is what the other 63 + 89 call sites correctly use.

Three call sites read the bare module globals instead, so they always see None:

line	function	consequence
1616	get_health	config_file check reports readable: false, status: "unknown"
1636	get_health	plugin_system check reports status: "not_initialized"
2471	get_display_current	panel geometry falls back to a hardcoded 128x64

Reproduction — /api/v3/health can never report healthy

On a rig where the config file is readable and the plugin system is demonstrably working (44 plugins installed and managed through this same blueprint's endpoints):

$ curl -s http://localhost:5000/api/v3/health
{
  "checks": {
    "config_file":   { "readable": false, "status": "unknown" },
    "plugin_system": { "status": "not_initialized" },
    "hardware":      { "snapshot_age_seconds": 82484.0, "status": "stale" }
  },
  "services": {
    "display_service": { "status": "active" },
    "web_interface":   { "status": "running" }
  },
  "status": "degraded"
}

But the config file is readable by the web service's user:

$ ls -l ~/LEDMatrix/config/config.json
-rw-r--r-- 1 hdpi hdpi 74046 Sep  4 17:45 config.json      # ledmatrix-web runs as hdpi

and the plugin system answers fine on the neighbouring endpoints (/api/v3/plugins/installed returns 44, /api/v3/plugins/state returns 52 entries).

Since all_healthy requires every check to be in ['accessible', 'operational', 'connected', 'running', 'active'], two permanently-wrong checks mean status is hardcoded to degraded in practice. The endpoint is unusable as a monitoring signal.

(The hardware: stale line has a separate cause — filed as #528.)

Reproduction — /api/v3/display/current reports the wrong panel size

$ curl -s http://localhost:5000/api/v3/display/current
{"data": {"width": 128, "height": 64, ...}}

Actual panel, from config/config.json:

cols=128 chain_length=2 rows=64 parallel=1  ->  256x64

get_display_current computes the geometry only if config_manager:, and otherwise falls back to width = 128; height = 64 — so every rig that isn't 128x64 gets wrong dimensions from this endpoint.

Suggested fix

Use the blueprint attributes, matching the rest of the file:

# line 1616
if api_v3.config_manager:
    test_config = api_v3.config_manager.load_config()
# line 1636
if api_v3.plugin_manager:
    ...
# line 2471
if api_v3.config_manager:
    main_config = api_v3.config_manager.load_config()

and delete the two module-level = None declarations so the mistake can't be made again — with them gone, a bare config_manager is a NameError at test time rather than a silent None in production.

Minor, same function

health_status['services']['web_interface'] = {
    'status': 'running',
    'uptime_seconds': time.time() - (getattr(get_health, '_start_time', time.time()))
}
get_health._start_time = getattr(get_health, '_start_time', time.time())

On the very first call the attribute isn't set yet, so uptime is computed from two independent time.time() calls and comes out as a small negative number — I saw -1.67e-06. Subsequent calls are correct (38.1s, 38.2s, 38.3s across three polls). Setting _start_time before computing the difference fixes it.

Environment

LEDMatrix v3.3.0-4-g0730d952, 256x64 rig, 44 plugins installed. Found while validating plugins.