[HeikoGr]

Fixes #4311

When several modules have a pending update and an updates command, only the first one was updated. The others were skipped without any message, in that check and every later one, until MagicMirror was restarted. As discussed in the issue, all pending updates are now applied by default.

Changes

update_helper.js

• parse() runs the pending updates one after another, not through Promise.all with a lock that was never released. updating now only keeps two update runs from overlapping (e.g. SCAN_UPDATES while a run is still going) and is reset in a finally block. inProgress is reset in the same way.
• A module whose update succeeded or failed is not tried again in the same MagicMirror run, so a broken command does not run again on every updateInterval. A restart tries it again.
• With updateAutorestart: true, MagicMirror restarts once after all updates are done. Before, the restart was scheduled 3 s after the first successful update and could cut off a later update that was still running.
• applyCommand() gets the module name as a string but checked isMagicMirror(module.module), which was always undefined. It now checks the name.

node_helper.js

• Sends UPDATE_STATUS for modules that were updated or failed. It used to check inProgress, which is now only true while an update runs.

updatenotification.js

• updates is now an object, not an array. It is filled with module names as keys, and Nunjucks loops over such an array as if it were empty. Because of this, the "Update done" / "Update error" lines were never shown.
• Removes the UPDATE_ERROR socket notification. The node helper never handled it, and the error is already logged by the helper.

Tests

• update_helper_spec.js: new tests for parse(). They cover: all modules updated in order with no overlap; real commands run in several temporary module folders; modules without a command skipped; a failed update not stopping the others; modules found in later checks updated; no retry of updated or failed modules; no second run while one is in progress; the lock released when an update throws; exactly one restart after all updates; no restart when every update failed. Also tests for applyCommand(). The old test "schedules node restart when autoRestart is enabled" now checks that updateProcess() itself no longer restarts.
• node_helper_spec.js: UPDATE_STATUS is sent only for updated or failed modules.
• New frontend_spec.js: renders the real updatenotification.njk with Nunjucks and checks the done, error and restart lines, plus deduplication per module. These tests fail with updates: [].
• Before the fix, the core parse() tests and all four template tests failed.
• node --run test:unit (527 tests) and node --run test:lint pass. node --run test:spelling reports the same 55 findings as develop, none in the changed files.

Also tested by hand with a serveronly instance and three local module repos that each had one new upstream commit (git pull, false, git pull):

	before	after
Modules updated	MMM-A only	MMM-A and MMM-C, MMM-B reported as failed
Mirror shows	"Restart required", B and C "update available", no line for A	"Restart required", ✓ A, ✗ B, ✓ C, B still "update available"
updateAutorestart: true	restart 3 s after A	one restart after all three, logged as 2 module(s) updated. followed by Restarting MagicMirror...

Docs

With this change, the "one module per run" behavior no longer needs to be documented. The updatenotification docs could still say that updates run one after another and that updateAutorestart restarts once after all of them. I can open a PR in the documentation repo if that helps.

🤖 Generated with Claude Code

[khassel]

I can open a PR in the documentation repo if that helps.

Yes, a pull request for the documentation would be great after this one has been merged. Please create the documentation pull request against develop, as this change will only take effect with the next release. Thanks!

[KristjanESPERANTO]

Looks good to me. As far as I can tell, there’s no option to get the previous behavior, but that might be overengineering. If anyone needs the old behavior, we can always add an option later.

Thanks for the PR! 🙂