nextcloud/server · error · BadRequestException

Parameters missing in order to complete the request. Missing

Error message

Parameters missing in order to complete the request. Missing Parameters: providerId

What it means

OCP\Federation\Exceptions\BadRequestException thrown by CalendarFederationProvider::notificationReceived() when the $providerId argument differs from PROVIDER_ID ('calendar'). The exception constructor turns the parameter list into 'Parameters missing in order to complete the request. Missing Parameters: providerId' and exposes getReturnMessage() for the OCM-style validation error body. In the normal OCS routing the provider id already selected this provider, so seeing it means a direct/mismatched call.

Source

Thrown at apps/dav/lib/CalDAV/Federation/CalendarFederationProvider.php:179

			]);
		} elseif ($this->invitationService->shouldAutoAccept($share->getOwner(), $calendar->getRemoteUrl())) {
			$this->invitationService->accept($calendar);
		} elseif ($isNew) {
			// A re-shared pending calendar keeps its original invitation
			$this->invitationService->notifyAboutNewShare($calendar);
		}

		return (string)$calendar->getId();
	}

	#[\Override]
	public function notificationReceived(
		$notificationType,
		$providerId,
		array $notification,
	): array {
		if ($providerId !== self::PROVIDER_ID) {
			throw new BadRequestException(['providerId']);
		}

		switch ($notificationType) {
			case CalendarFederationNotifier::NOTIFICATION_SYNC_CALENDAR:
				return $this->handleSyncCalendarNotification($notification);
			default:
				return [];
		}
	}

	/**
	 * @return string[]
	 */
	#[\Override]
	public function getSupportedShareTypes(): array {
		return [self::USER_SHARE_TYPE];
	}

View on GitHub (pinned to ecdeb153ff)

Solutions

Always pass providerId exactly 'calendar' (CalendarFederationProvider::PROVIDER_ID) when calling notificationReceived().
When POSTing to the cloud federation API notification endpoint, set the providerId request parameter to 'calendar'.
In tests, derive the id from the constant instead of a string literal.

Example fix

// before
$provider->notificationReceived('SYNC_CALENDAR', 'calendars', $notification);

// after
$provider->notificationReceived(
	\OCA\DAV\CalDAV\Federation\CalendarFederationNotifier::NOTIFICATION_SYNC_CALENDAR,
	\OCA\DAV\CalDAV\Federation\CalendarFederationProvider::PROVIDER_ID,
	$notification,
);

Defensive patterns

Strategy: validation

Validate before calling

use OCA\DAV\CalDAV\Federation\CalendarFederationProvider;
if ($providerId !== CalendarFederationProvider::PROVIDER_ID) {
    $providerId = CalendarFederationProvider::PROVIDER_ID; // 'calendar'
}
$provider->notificationReceived($notificationType, $providerId, $notification);

Try / catch

try {
    $provider->notificationReceived($type, $providerId, $notification);
} catch (\OCP\Federation\Exceptions\BadRequestException $e) {
    // getReturnMessage() lists the offending parameter; fix providerId and re-send
}

Prevention

Reference PROVIDER_ID constants instead of string literals for provider ids.
In tests, seed providerId from the same constant used at registration.

When it happens

Trigger: Invoking notificationReceived() directly (tests, custom federation code) with a providerId other than 'calendar'; POSTing to the cloud federation notifications endpoint with a providerId that does not equal CalendarFederationProvider::PROVIDER_ID but reaching this provider anyway.

Common situations: Unit tests that pass a placeholder providerId; copy-pasted provider wiring where the registered id and the dispatched id diverge; client integrations sending providerId 'calendarFederation' or 'calendars' instead of 'calendar'.

Related errors

AI-assisted analysis of nextcloud/server@ecdeb153ff (2026-08-17). Data as JSON: /api/errors/164effbe742c5f10. Report an issue: GitHub.