Cross-correlation: raise ValueError when fewer than two signal regions are present and surface error to frontend UI

[Copilot]

• Raise ValueError in execute_compute_cross_correlation when fewer than two signal regions are present (single-region and zero-region messages)
• Update getCorrCombinations to return single region name instead of empty list
• Surface error messages to Panel frontend UI via PB_ERROR_FILE mechanism and pn.state.notifications.error
• Add/update unit tests (psth_utils, psth orchestration, progress)
• Update CHANGELOG.md
• Mark readPBIncrementValues tests with @pytest.mark.progress_bar; skip on Windows in CI; add # pragma: no cover to readPBIncrementValues (see issue Refactor progress bar to remove file-based backend #286)

[pauladkisson]

This actually looks pretty good on the backend side, but I would like this error message to surface to the frontend so that users know that something has gone wrong when they click step five and they don't have to go digging into the terminal.

[Copilot]

This actually looks pretty good on the backend side, but I would like this error message to surface to the frontend so that users know that something has gone wrong when they click step five and they ...

Done in commit 797e3a0. The error message is now surfaced to the Panel UI via a toast notification:

• Added PB_ERROR_FILE (~/pbError.txt) — each subprocess main() (psth, preprocess, read_raw_data) writes the exception message there before writing the -1 failure sentinel to the progress file (order guarantees the file is present when the frontend reads it).
• readPBIncrementValues now reads and returns the error message from that file when it detects -1, then cleans it up.
• home.py enables pn.extension(notifications=True) and calls pn.state.notifications.error(error_msg, duration=0) after each step button click if an error message was returned — so users see a persistent red toast notification directly in the UI without needing to check the terminal.

[pauladkisson]

This looks amazing. The error pop-up is beautiful.

[pauladkisson]

@copilot please update the change log.

[Copilot]

@copilot please update the change log.

Done in commit d7eff42 — added an entry under Fixes in the v2.0.0-alpha5 section of CHANGELOG.md.

[codecov]

Codecov Report

❌ Patch coverage is 40.00000% with 15 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/guppy/orchestration/home.py	10.00%	9 Missing ⚠️
src/guppy/orchestration/preprocess.py	33.33%	2 Missing ⚠️
src/guppy/orchestration/psth.py	71.42%	2 Missing ⚠️
src/guppy/orchestration/read_raw_data.py	33.33%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[pauladkisson]

Unfortunately, these tests fail on Windows due to threading and file lock issues. I think the cleanest solution to this problem is to mark those tests as progress bar tests and/or something like that. I think progress bar tests, and then skip them in the CI so that they don't run on Windows, but they can be run locally. Add a pragma: no cover to the read PB increment values function, along with a comment explaining why it cannot be tested with a reference to this issue.

#286

[Copilot]

Unfortunately, these tests fail on Windows due to threading and file lock issues. I think the cleanest solution to this problem is to mark those tests as progress bar tests and/or something like that....

Done in commit 3363c4e:

• Added a progress_bar marker to pyproject.toml (with a description noting it's skipped on Windows in CI due to issue Refactor progress bar to remove file-based backend #286).
• Decorated both readPBIncrementValues tests in test_progress.py with @pytest.mark.progress_bar.
• Updated .github/workflows/run-tests.yml to append and not progress_bar to the marker expression when runner.os == 'Windows'.
• Added # pragma: no cover to readPBIncrementValues in progress.py with a docstring comment explaining why (threading/file-lock behaviour unreliable on Windows in CI) and referencing issue Refactor progress bar to remove file-based backend #286.