Matterbridge: checkBridgeProcess() rejects valid bridges after #19820 #20044

What happened

After a Nextcloud AIO container update/recreation, my existing Talk ↔ Matrix Matterbridge stopped working. The bridge was still saved in oc_talk_bridges with enabled=1 and an old PID, but the process was gone, along with its generated /tmp/bridge-*.toml and .log files.

Talk no longer showed/recovered the bridge correctly. The process-state endpoint failed, and running the registered OCA\Talk\BackgroundJob\CheckMatterbridges job did not bring the bridge back.

I initially suspected a bad Matrix configuration, but the saved bridge parts were intact. I tracked the failure down to two lines in lib/MatterbridgeManager.php, both introduced by #19820.

How to reproduce

1. Set up and enable a working Matterbridge integration in Talk.
2. Recreate the Nextcloud application container (or otherwise stop the bridge), leaving its database row enabled with a stale PID and no generated runtime files.
3. Request GET /ocs/v2.php/apps/spreed/api/v1/bridge/{token}/process or run the CheckMatterbridges background job.
4. Check the Nextcloud log and the bridge process state.

Expected: Talk recognizes that the process is gone. The status request reports it as stopped, and the background job restarts the enabled bridge.

Actual: The bridge is treated as an invalid/malicious configuration. The process is not restarted, and the exception handler produces a second database error.

Relevant log messages:

User tried to configure a malicious matterbridge setup
Invalid matterbridge parameters
Invalid query type, expected SELECT query

What I found

In checkBridgeProcess(), the new validation call is:

$this->validateParts($bridge);

But $bridge is the wrapper returned by getBridgeFromDb(), containing enabled, pid, and parts. validateParts() expects the numerically indexed parts array. It immediately rejects the wrapper's string keys, even when the stored Matterbridge configuration is valid.

The call should be:

$this->validateParts($bridge['parts']);

There's a second problem in the same exception handler: it builds an UPDATE talk_bridges statement, then calls executeQuery() and closeCursor(). On my PostgreSQL installation this fails with Invalid query type, expected SELECT query. That should use executeStatement() instead.

Both changes appear in #19820, and both are still present in the current source.

Local verification

I changed only validateParts($bridge) to validateParts($bridge['parts']) locally and checked the PHP syntax. After running Talk's registered CheckMatterbridges job:

• the dead PID was detected and replaced with a running Matterbridge process;
• the missing TOML and log files were recreated;
• the existing database configuration and credentials remained untouched;
• fresh plain-text messages worked in both directions (Talk → Matrix and Matrix → Talk).

I didn't apply the separate executeStatement() fix locally; that part follows from the failing UPDATE code path and the DBAL error.

Environment

• Nextcloud AIO (Docker), PostgreSQL
• Talk 24.0.6 and talk_matterbridge 1.35.1026000 observed before an available update
• Matterbridge binary 1.26.0
• Matrix homeserver: Conduit
• I also installed the available AIO/Talk update while investigating; the problem persisted. I don't have the exact post-update version recorded.

Possibly related at the UI/symptom level: #8793, although that older issue predates the regression introduced in #19820.