This turns out to be tricky to test, because the array that is created with the padded values doesn't survive the exporting process. But here's a demonstration:

(Pdb) p pad_width
999
(Pdb) p data.shape
(4, 1001)
(Pdb) data2 = np.pad(data, (0, int(pad_width)), "edge")
(Pdb) p data2.shape
(1003, 2000)  # <----- went from 4 channels to 1003 channels

the reason it doesn't show up in the output is that there's later a loop over the channels in the original raw so the excess spurious channels (which are always at the end) are never added to the list of EDFSignals that ultimately get written to file. In lieu of a test, I've stuck a couple assert statements inline that cause the existing test_edf_padding test to fail on main.

CI fails look like they might all be due to random number generator issues?

Linux pip-pre

• assert_allclose: mne/forward/tests/test_make_forward.py::test_make_forward_dipole:721
• assert_allclose: mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[fil]:292
• mne/preprocessing/tests/test_maxwell.py::test_other_systems - RuntimeWarning: Estimated head radius (10.9 cm) is above the 99th percentile for adult head size
• assert median difference < tolerance: mne/simulation/tests/test_raw.py::test_simulate_raw_bem[testing_data]:398

Windows pip-pre

• mne/preprocessing/tests/test_fine_cal.py::test_compute_fine_cal[VectorView] - assert 62 < np.float64(61.578209335821576)
• mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[kit] - AssertionError: Shielding factor not 2.300 <= 2.275 < 2.800
  assert 2.3 <= np.float64(2.2748473564245675)
• mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[ctf] - RuntimeError: No usable segments found
• mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[fil] - AssertionError: Shielding factor not 125.000 <= 152.489 < 145.000
  assert np.float64(152.4889126829783) < 145
• mne/decoding/tests/test_search_light.py::test_search_light_basic

Locally I have NumPy 2.1.3 (currently numba forbids anything higher), but regardless I can't find anything in the NumPy changelogs from 2.1.3 onward that seems likely to affect assert_allclose or NumPy's random generators (this is the closest: numpy/numpy#28006). Needs further investigation.

Often these things crop up due to some change in linalg, like an update to OpenBLAS for example. It changes slightly the results of pseudo-inversion etc. and so some tolerances are too strict. We usually just bump them as long as they aren't way out of range. These all look bumpable to me

Often these things crop up due to some change in linalg, like an update to OpenBLAS for example. It changes slightly the results of pseudo-inversion etc. and so some tolerances are too strict. We usually just bump them as long as they aren't way out of range. These all look bumpable to me

OK, I bumped whatever I could figure out how to bump. I suspect that these two won't actually be fixed by my changes though:

• mne/preprocessing/tests/test_maxwell.py::test_other_systems - RuntimeWarning: Estimated head radius (10.9 cm) is above the 99th percentile for adult head size (because I was unable to reproduce, I wasn't even sure which system was causing the warning)

• mne/decoding/tests/test_search_light.py::test_search_light_basic (unexpected skip: sklearn int_t / long long mismatch which AFAICT should not be happening anymore?)

Okay I think the differences are due to changes in fmin_cobyla actually. In theory the results should now be more accurate, but it does mean that some of our checks will need to change a bit

... I'll merge this one as-is and then open a separate PR for the cobyla stuff.

Thanks @drammock !