Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Matterbridge: checkBridgeProcess() rejects valid bridges after #19820

Open Beginner friendly
  • Is something wrong?
#20,044 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php, postgresql
Domain
backend, databases

Research direction

Start in lib/MatterbridgeManager.php at checkBridgeProcess() and review the validateParts() call and the exception handler’s database update. Change the validation input to the stored parts array and use the database API appropriate for an UPDATE. Verify that a stale bridge process is reported as stopped and restarted by CheckMatterbridges, and that the handler does not produce a database query error.

Written by the indexing model from the issue text.

Description

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.

Dominant language
JavaScript
Stars
2.2k
Forks
598
Avg merge
21h 19m
Merged PRs (30d)
370

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nextcloud/spreed

All issues in nextcloud/spreed

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.