[Bug]: Unified search returns HTTP 500 on PHP 8 when the `cursor` parameter is empty ("Unsupported operand types: string + int")

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#66,623 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
66/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
php
Bereich
backend

Rechercherichtung

Die fünf Absturzstellen sind in der Tabelle aufgeführt: apps/files/lib/Search/FilesSearchProvider.php (etwa Zeile 143), apps/dav/lib/Search/ContactsSearchProvider.php, apps/dav/lib/Search/EventsSearchProvider.php, apps/dav/lib/Search/TasksSearchProvider.php und apps/systemtags/lib/Search/TagSearchProvider.php. Beginne damit, den 500er-Fehler mit einem leeren cursor am Endpunkt der Provider-Suche zu reproduzieren, und finde dann heraus, wo jeder Provider den nächsten Cursor aus getCursor() berechnet. Fertig ist es, wenn ein leerer Cursor bei jedem Provider 200 zurückgibt und ein Maintainer sich zwischen dem providerspezifischen Cast und einer Normalisierung in SearchQuery::getCursor() entschieden hat.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

0. Needs triage 35-feedback bug
⚠️ This issue respects the following points: ⚠️
  • This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
  • This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
  • I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
  • I agree to follow Nextcloud's Code of Conduct.
  • I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.
Bug description

Unified search is completely broken on PHP 8: every search request returns HTTP 500 and the UI shows "No matches found" even when matching files exist.

Every search provider computes the next cursor as:

$query->getCursor() + <int>

When the web frontend sends an empty cursor query parameter (which it does on the first search), getCursor() returns an empty string. On PHP 8, '' + int throws a TypeError instead of coercing to 0 as PHP 7 did. The provider crashes, the OCS endpoint returns 500, and the frontend - which receives an error rather than an empty result set - renders "No matches found".

This affects five providers across three apps, so file, contacts, calendar, tasks and tag search all break at once. Because unified search queries every provider, a single failing one is enough to make the whole search look empty.

File Line Code
apps/files/lib/Search/FilesSearchProvider.php 143 $query->getCursor() + $query->getLimit()
apps/dav/lib/Search/ContactsSearchProvider.php 130 $query->getCursor() + count($formattedResults)
apps/dav/lib/Search/EventsSearchProvider.php 207 $query->getCursor() + count($uniqueResults)
apps/dav/lib/Search/TasksSearchProvider.php 139 $query->getCursor() + count($searchResults)
apps/systemtags/lib/Search/TagSearchProvider.php 149 $query->getCursor() + $query->getLimit()
Steps to reproduce
  1. Run Nextcloud 35.x on PHP 8 (reproduced on PHP 8.5.4).
  2. Log in to the web UI and open the Files app.
  3. Type into the unified search bar any term matching an existing file.
  4. The dropdown shows "No matches found" even though the file exists.
  5. The browser console shows: unified-search: Unexpected AxiosError "Request failed with status code 500".

The failure can be isolated with direct requests. The empty cursor is the only variable that changes between 200 and 500:

# 200, returns results:
/ocs/v2.php/search/providers/files/search?term=<term>&from=%2Fapps%2Ffiles%2Ffiles

# 200, returns results:
/ocs/v2.php/search/providers/files/search?term=<term>&from=%2Fapps%2Ffiles%2Ffiles&cursor=0

# 500:
/ocs/v2.php/search/providers/files/search?term=<term>&from=%2Fapps%2Ffiles%2Ffiles&cursor=
Expected behavior

An empty cursor should be treated as "no cursor" (i.e. 0) and the search should return results normally, as it did on PHP 7.

Actual behaviour: the provider throws, the endpoint returns HTTP 500, and the UI reports no matches.

Nextcloud Server version

35

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 31 to 32)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?
  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Exception: Unsupported operand types: string + int in file
'/var/www/html/apps/dav/lib/Search/EventsSearchProvider.php' line 207

URL: /ocs/v2.php/search/providers/calendar/search?term=<term>&from=%2Fapps%2Ffiles%2Ffiles&cursor=

The same exception is raised by each affected provider at the line listed in the description.
Additional info
Suggested fix

Cast the cursor before the addition, so an empty value becomes 0:

(int)$query->getCursor() + $query->getLimit()

Applying that one-line change to the five files listed above restores unified search completely. Verified locally: all nine registered providers return HTTP 200 afterwards, including with &cursor= empty.

A more central alternative would be to normalise the value in SearchQuery::getCursor() itself, or when the OCS controller parses the request, so providers never receive an empty string.

Notes
  • The regression is invisible on PHP 7, where '' + int evaluates to the integer with only a notice. It only surfaces once the server runs PHP 8, which makes it easy to miss and hard for users to attribute: the search simply looks like it finds nothing.
  • Reproduced on 35.0.2 and again on 35.0.3. The 35.0.3 update overwrote a local patch and the bug returned, so the affected code is unchanged between those releases.
App versions of the affected apps
  • files: 3.0.0
  • dav: 2.0.1
  • systemtags: 2.0.0
Vorherrschende Sprache
PHP
Sterne
37.5k
Forks
5.4k
Ø Merge
1 T. 14 Std.
Gemergte PRs (30 T.)
648

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus nextcloud/server

Alle Issues in nextcloud/server

Ähnliche Issues

Weitere Issues zu PHP

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.