The commit-confirm timer starts before the commit runs. When the commit takes longer than the confirm time (minutes on large configs), three things go wrong, measured with a 150 s commit and commit-confirm 1:

1. action reboot (the default): the timer fires during the commit and the router reboots 80 s into it; after the boot the old saved configuration is active.
2. action reload: the timer fires 65 s into the commit, the terminal shows [commit-confirm] Reverting to previous config now, but the revert is refused ("Configuration system temporarily locked due to another commit in progress"); the unconfirmed change stays active and confirm answers "No confirm pending".
3. After (2), commit-confirm.service stays in the failed state, and every later commit-confirm fails with "Failed to start transient timer unit: Unit commit-confirm.service was already loaded" without committing anything, until systemctl reset-failed or a reboot.

Potential fix direction: Start the timer when the commit finishes (post-commit), not before it; make the revert wait for or retry the commit lock instead of failing; clear a failed unit before arming.