Event::generateEvents() rejects the pattern 'project.delete' because
it parses 'delete' as a resource that must be present in route params.
The pre-migration route did not declare an event label, so functions
and webhooks were never triggered on project deletion. Restore that
behavior by removing the label.
The migrations worker (Appwrite→Appwrite migrations + CSV/JSON imports
& exports) reads `_APP_MIGRATION_HOST` to call back into this instance's
API. `_APP_MIGRATION_HOST` was introduced in #11229 (1.8.x / 1.9.x) but
was never added to `app/config/variables.php`, so `appwrite install` /
`appwrite upgrade` never write it into the generated `.env`. With the
var unset, the migrations worker fails — on a fresh self-hosted install
the first export hangs with no error (#11853). (Contributors and CI
don't hit it because the repo's hand-maintained `.env` already has
`_APP_MIGRATION_HOST=appwrite`; only the *installer-generated* `.env` is
missing it.)
Add `_APP_MIGRATION_HOST` to `app/config/variables.php` with default
`appwrite` — the API service name in the standard Docker Compose setup,
which is what the repo's own `.env` and the cloud Helm charts already
use, and what the migration endpoint was hardcoded to before #11229.
`appwrite install` and `appwrite upgrade` now write it into the
generated `.env`, so fresh installs and upgrades have it set and the
migration/import/export flows work.
Scope: this PR fixes the install & upgrade paths only — it deliberately
doesn't change the worker code.
Fixes#11853
Replaces the inline match closure with resolveDestinationDatabaseDsn(),
mirroring cloud's worker. Adds a docblock explaining why documentsdb /
vectorsdb keep the source DSN.
Endpoint deleted in 96fe989f6d ("update composer dependencies and remove
obsolete log classes") but the two test methods calling it were left
behind. They have been failing with 404 on every PR since.
Migration lib 1.10.2's getDatabaseDSN resolver returns the value
written into destination's _databases.database. The previous resolver
always returned the project's main DSN (mongodb in default CI) for
every database type, including documentsdb / vectorsdb — which are
routed to their own adapters (mongodb / postgresql) per
_APP_DB_ADAPTER_DOCUMENTSDB / _APP_DB_ADAPTER_VECTORSDB.
The wrong DSN routed vectorsdb attribute creates back to mongodb,
producing 'Vector types are not supported by the current database'
on the MixedDatabases / VectorsDB migration tests.
Mirror cloud's resolver: keep the source DSN for documentsdb /
vectorsdb (they target dedicated hosts), use destination project's
main DSN otherwise.
Matej Bačo
Atharva Deosthale
Jake Barnby
Damodar Lohani
Damodar Lohani
Chirag Aggarwal
premtsd-code
Levi van Noort
Matej Bačo