⚠️ This issue respects the following points: ⚠️
Bug description
Bug description
The federated_invites table can get silently dropped by an unversioned
repair step in cloud_federation_api, even though the contacts app
now owns and expects this table.
Expected behaviour
The repair step should not drop a table that another currently active
app expects/owns. At minimum it should check whether contacts is
installed/enabled and skip the drop in that case, or the repair step
should be removed now that contacts is the canonical owner and has
its own CreateTable migration.
Actual behaviour
federated_invites can end up missing on instances that have both
apps' migrations applied, requiring manual recreation of the table.
Environment
- Nextcloud version: 35.0.0.10
- Found via:
occ db:schema:check --output=json_pretty (new in 35.0)
Relevant files
apps/cloud_federation_api/lib/Migration/DropFederatedInvitesTable.php
apps/cloud_federation_api/lib/Migration/Version1016Date202502262004.php
apps/contacts/lib/Migration/Version8004Date20260130131217.php
apps/contacts/lib/Migration/Version8005Date20260418120000.php
apps/cloud_federation_api/appinfo/info.xml (<repair-steps> block)
Steps to reproduce
Steps to reproduce
federated_invites was originally created by
cloud_federation_api's migration
Version1016Date202502262004 (CreateTable, OCM Invitation Flow).
- The OCM invite feature was later moved to the
contacts app, which
has its own, identical CreateTable migration
Version8004Date20260130131217, plus a follow-up migration
Version8005Date20260418120000 that alters the accepted column
and adds a partial unique index.
cloud_federation_api still ships a <post-migration> repair step
OCA\CloudFederationAPI\Migration\DropFederatedInvitesTable
(registered in appinfo/info.xml, no version constraint), which
unconditionally drops federated_invites if the table is empty —
with no check for whether another app (now contacts) has taken
ownership of it.
- On an instance where
federated_invites had no rows yet (OCM
invites never used), a later version bump of cloud_federation_api
re-ran this repair step and dropped the table that contacts had
already created and was relying on.
occ db:schema:check (new in 35.0) then reports:
even though occ status shows needsDbUpgrade: false and
occ app:update contacts / occ upgrade report nothing to do,
since both apps' migrations are already fully recorded as executed
in oc_migrations — only the repair step's side effect removed the
table afterwards.
Expected behavior
Expected behaviour
The repair step should not drop a table that another currently active
app expects/owns. At minimum it should check whether contacts is
installed/enabled and skip the drop in that case, or the repair step
should be removed now that contacts is the canonical owner and has
its own CreateTable migration.
Actual behaviour
federated_invites can end up missing on instances that have both
apps' migrations applied, requiring manual recreation of the table.
Environment
- Nextcloud version: 35.0.0.10
- Found via:
occ db:schema:check --output=json_pretty (new in 35.0)
Relevant files
apps/cloud_federation_api/lib/Migration/DropFederatedInvitesTable.php
apps/cloud_federation_api/lib/Migration/Version1016Date202502262004.php
apps/contacts/lib/Migration/Version8004Date20260130131217.php
apps/contacts/lib/Migration/Version8005Date20260418120000.php
apps/cloud_federation_api/appinfo/info.xml (<repair-steps> block)
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?
None
What user-backends are you using?
Configuration report
www-data@cloud:~ $ php /daten/websites/nextcloud/occ config:list system
{
"system": {
"integrity.check.disabled": true,
"enable_previews": "true",
"preview_lib": "gd",
"preview_max_threads": 2,
"serverid": 1,
"memcache.local": "\\OC\\Memcache\\APCu",
"memcache.distributed": "\\OC\\Memcache\\Redis",
"memcache.locking": "\\OC\\Memcache\\Redis",
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"cloud.infosoft.ch",
"cloud.infosoft.ch",
"127.0.0.1"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "35.0.0.10",
"overwrite.cli.url": "https:\/\/cloud.infosoft.ch",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"config_preset": 2,
"maintenance": false,
"default_phone_region": "CH",
"maintenance_window_start": 100,
"trusted_proxies": "***REMOVED SENSITIVE VALUE***",
"forbidden_filename_characters": [
"\\",
"\/"
],
"forbidden_filename_extensions": [
".filepart",
".part"
],
"theme": "",
"loglevel": 2,
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtpmode": "smtp",
"mail_smtpsecure": "ssl",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpauth": true,
"mail_smtpport": "465",
"mail_sendmailmode": "smtp",
"mail_smtpstreamoptions": {
"ssl": {
"allow_self_signed": true,
"verify_peer": false,
"verify_peer_name": false
}
},
"updater.release.channel": "stable",
"defaultapp": "dashboard,files,photos,contacts"
}
}
List of activated Apps
www-data@cloud:~ $ php /daten/websites/nextcloud/occ app:list
Enabled:
- appstore: 2.0.0-dev.0
- calendar: 6.5.4
- cloud_federation_api: 2.0.0-dev.0
- comments: 2.0.0-dev.0
- contacts: 8.9.0
- contactsinteraction: 2.0.0-dev.0
- dashboard: 8.0.0-dev.0
- dav: 2.0.0-dev.1
- federatedfilesharing: 2.0.0-dev.1
- files: 3.0.0-dev.0
- files_pdfviewer: 8.0.0
- files_sharing: 2.0.0-dev.1
- files_trashbin: 2.0.0-dev.0
- groupfolders: 23.0.1
- guests: 4.10.0
- logreader: 8.0.0
- lookup_server_connector: 2.0.0-dev.0
- mail: 5.12.0
- notes: 6.1.0
- notifications: 8.0.0
- notify_push: 1.4.1
- oauth2: 2.0.0-dev.0
- office: 1.1.0
- passwords: 2026.10.20-build6018
- photos: 8.0.0
- profile: 2.0.0-dev.0
- provisioning_api: 2.0.0-dev.0
- richdocuments: 12.0.0
- serverinfo: 7.0.0
- settings: 2.0.0-dev.0
- sharing: 1.0.4
- text: 9.0.0
- theming: 3.0.0-dev.0
- twofactor_backupcodes: 2.0.0-dev.0
- updatenotification: 2.0.0-dev.0
- user_migration: 10.5.0
- user_status: 2.0.0-dev.0
- viewer: 8.0.0
- workflowengine: 3.0.0-dev.0
Disabled:
- activity: 8.0.0 (installed 7.0.0)
- admin_audit: 2.0.0-dev.0 (installed 1.23.0)
- app_api: 35.0.0 (installed 34.0.0)
- bruteforcesettings: 8.0.0 (installed 6.0.0)
- circles: 35.0.0 (installed 34.0.0)
- encryption: 3.0.0-dev.0
- federation: 2.0.0-dev.0 (installed 1.24.0)
- files_downloadlimit: 5.3.0 (installed 5.2.0-dev.0)
- files_external: 2.0.0-dev.0
- files_lock: 35.0.0 (installed 34.0.0)
- files_reminders: 2.0.0-dev.0 (installed 1.7.0)
- files_versions: 2.0.0-dev.0 (installed 1.27.0)
- firstrunwizard: 8.0.0 (installed 7.0.0-dev.0)
- keeweb: 0.6.28 (installed 0.6.28)
- maps: 1.7.1 (installed 1.7.1)
- nextcloud_announcements: 7.0.0 (installed 5.0.0)
- password_policy: 7.0.0 (installed 6.0.0-dev.0)
- privacy: 7.0.0 (installed 6.0.0-dev.1)
- recommendations: 8.0.0 (installed 7.0.0-dev.0)
- related_resources: 6.0.0 (installed 5.0.0-dev.0)
- richdocumentscode_arm64: 26.4.104 (installed 26.4.104)
- sharebymail: 2.0.0-dev.0 (installed 1.24.0)
- support: 7.0.0 (installed 6.0.0)
- survey_client: 7.0.0 (installed 6.0.0-dev.0)
- suspicious_login: 13.0.0
- systemtags: 2.0.0-dev.0 (installed 1.23.0)
- twofactor_nextcloud_notification: 9.0.0 (installed 8.0.0)
- twofactor_totp: 17.1.0 (installed 16.0.0)
- twofactor_webauthn: 2.7.0 (installed 2.7.0)
- user_ldap: 2.0.0-dev.0
- weather_status: 2.0.0-dev.0 (installed 1.14.0)
- webhook_listeners: 2.0.0-dev.0 (installed 1.5.0)
- wopi: 3.5.11 (installed 3.5.11)
www-data@cloud:~ $
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
Additional info
No response
Bug description
Bug description
The
federated_invitestable can get silently dropped by an unversionedrepair step in
cloud_federation_api, even though thecontactsappnow owns and expects this table.
Expected behaviour
The repair step should not drop a table that another currently active
app expects/owns. At minimum it should check whether
contactsisinstalled/enabled and skip the drop in that case, or the repair step
should be removed now that
contactsis the canonical owner and hasits own
CreateTablemigration.Actual behaviour
federated_invitescan end up missing on instances that have bothapps' migrations applied, requiring manual recreation of the table.
Environment
occ db:schema:check --output=json_pretty(new in 35.0)Relevant files
apps/cloud_federation_api/lib/Migration/DropFederatedInvitesTable.phpapps/cloud_federation_api/lib/Migration/Version1016Date202502262004.phpapps/contacts/lib/Migration/Version8004Date20260130131217.phpapps/contacts/lib/Migration/Version8005Date20260418120000.phpapps/cloud_federation_api/appinfo/info.xml(<repair-steps>block)Steps to reproduce
Steps to reproduce
federated_inviteswas originally created bycloud_federation_api's migrationVersion1016Date202502262004(CreateTable, OCM Invitation Flow).contactsapp, whichhas its own, identical
CreateTablemigrationVersion8004Date20260130131217, plus a follow-up migrationVersion8005Date20260418120000that alters theacceptedcolumnand adds a partial unique index.
cloud_federation_apistill ships a<post-migration>repair stepOCA\CloudFederationAPI\Migration\DropFederatedInvitesTable(registered in
appinfo/info.xml, no version constraint), whichunconditionally drops
federated_invitesif the table is empty —with no check for whether another app (now
contacts) has takenownership of it.
federated_inviteshad no rows yet (OCMinvites never used), a later version bump of
cloud_federation_apire-ran this repair step and dropped the table that
contactshadalready created and was relying on.
occ db:schema:check(new in 35.0) then reports:even though
occ statusshowsneedsDbUpgrade: falseandocc app:update contacts/occ upgradereport nothing to do,since both apps' migrations are already fully recorded as executed
in
oc_migrations— only the repair step's side effect removed thetable afterwards.
Expected behavior
Expected behaviour
The repair step should not drop a table that another currently active
app expects/owns. At minimum it should check whether
contactsisinstalled/enabled and skip the drop in that case, or the repair step
should be removed now that
contactsis the canonical owner and hasits own
CreateTablemigration.Actual behaviour
federated_invitescan end up missing on instances that have bothapps' migrations applied, requiring manual recreation of the table.
Environment
occ db:schema:check --output=json_pretty(new in 35.0)Relevant files
apps/cloud_federation_api/lib/Migration/DropFederatedInvitesTable.phpapps/cloud_federation_api/lib/Migration/Version1016Date202502262004.phpapps/contacts/lib/Migration/Version8004Date20260130131217.phpapps/contacts/lib/Migration/Version8005Date20260418120000.phpapps/cloud_federation_api/appinfo/info.xml(<repair-steps>block)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?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response