VisualTestDisplayManager.set_scrolling_state() is missing frame_hold — check_plugin.py fails 8/8 sizes for ledmatrix-stocks

[ChuckBuilds]

Summary

VisualTestDisplayManager.set_scrolling_state() never picked up the frame_hold parameter that the real DisplayManager gained. Any plugin that passes it raises TypeError at render time, so scripts/check_plugin.py — and the visual/golden test path built on it — fails on every size for that plugin.

ledmatrix-stocks (v2.9.0) is currently the only plugin affected, and it therefore has no working visual regression coverage at all.

The divergence

src/display_manager.py:1341:

def set_scrolling_state(self, is_scrolling: bool, frame_hold: int = 1):

src/plugin_system/testing/visual_display_manager.py:506:

def set_scrolling_state(self, is_scrolling: bool):
 """Set the current scrolling state (no-op for testing)."""

Reproduction

LEDMatrix v3.3.0-4-g0730d952, ledmatrix-stocks 2.9.0:

cd ~/LEDMatrix
python3 scripts/check_plugin.py -p ledmatrix-stocks -d ~/LEDMatrix/plugin-repos

[FAIL] 64x32 stocks error=TypeError("VisualTestDisplayManager.set_scrolling_state() got an unexpected keyword argument 'frame_hold'")
[FAIL] 128x32 stocks error=TypeError(...)
[FAIL] 64x64 stocks error=TypeError(...)
[FAIL] 96x48 stocks error=TypeError(...)
[FAIL] 128x64 stocks error=TypeError(...)
[FAIL] 256x32 stocks error=TypeError(...)
[FAIL] 128x96 stocks error=TypeError(...)
[FAIL] 256x128 stocks error=TypeError(...)

8/8 sizes, rc=1. Every other installed plugin on the rig renders; this one cannot be rendered by the harness at all.

Caller

ledmatrix-stocks/manager.py:193, and the comment there shows the call is deliberate and correct against the real core:

# Pass the frame hold every time scrolling starts, not once at
# construction: plugins share one display manager, so a hold set at
# init is wiped as soon as any other plugin finishes its scroll.
self.display_manager.set_scrolling_state(
 True, frame_hold=self._scroll_frame_hold())

The plugin already guards for one harness divergence two lines below (hasattr(self.display_manager, "process_deferred_updates")), so the shape of the problem is known — this one just wasn't covered.

Suggested fix

Match the signature in the test double:

def set_scrolling_state(self, is_scrolling: bool, frame_hold: int = 1):
 self._scrolling_state['is_scrolling'] = is_scrolling
 self._scrolling_state['frame_hold'] = frame_hold
 if is_scrolling:
 self._scrolling_state['last_scroll_activity'] = time.time()

More generally: this class of drift is silent until a plugin happens to use the new argument. A test that asserts VisualTestDisplayManager's public methods are signature-compatible with DisplayManager's (via inspect.signature) would catch the next one at core-commit time rather than at plugin-render time.

Environment

256x64 rig, LEDMatrix v3.3.0-4-g0730d952. Found while rendering all 44 installed plugins through check_plugin.py.

[ChuckBuilds]

Correction to the original report: I wrote that ledmatrix-stocks was "currently the only plugin affected". That is no longer true, and the blast radius is wider than one plugin.

Nine first-party plugins now call set_scrolling_state(..., frame_hold=...):

stock-news ledmatrix-elections ledmatrix-leaderboard march-madness
odds-ticker text-display news ledmatrix-stocks nfl-draft

Re-running each at 128x64 against the current sources:

plugin	harness result today
ledmatrix-stocks	FAIL — TypeError: ... unexpected keyword argument 'frame_hold'
ledmatrix-leaderboard	FAIL — same
stock-news, ledmatrix-elections, march-madness, odds-ticker, text-display, news, nfl-draft	pass

The seven that pass are not guarded against this — they simply don't reach the call under harness conditions (no data, so the scroll path returns early). The call site is the same unguarded shape in all nine, e.g. news/manager.py:1104:

self.display_manager.set_scrolling_state(
 True, frame_hold=self._scroll_frame_hold())

and ledmatrix-leaderboard/manager.py:342 is identical. odds-ticker:2980 guards on the method existing (hasattr(self.display_manager, 'set_scrolling_state')) but not on the keyword being accepted, so it fails the same way once its scroll path runs.

So the practical effect is that the visual harness cannot exercise the scrolling path of any of these nine — the two that reach it fail outright, and the other seven only pass because they render nothing. Fixing the signature in VisualTestDisplayManager unblocks all nine at once.

One caveat on the timeline, in case it matters to whoever picks this up: at 17:20 today a grep -rln frame_hold plugin-repos/ on this rig matched only ledmatrix-stocks; by 18:25 it matched all nine, with the nine manager.py files rewritten in two batches (18:20:21-23 and 18:25:03-04) and most manifest versions unchanged. I could not establish what performed those writes — it wasn't a store install/update, a git operation, cron, a systemd timer, or anything logged by either service. Flagging it because it means the nine files on this rig may not correspond to a tagged release.