Each SDK method now points at its own markdown file under
docs/references/advisor/ instead of an inline heredoc, matching the
house convention used by every other module.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
utopia-php/migration 1.10.2 stopped propagating the source DSN to the
destination's `_databases.database` and added an opt-in `getDatabaseDSN`
resolver. Without it, the destination DB row gets a blank `database`
field, so reads on documentsdb/vectorsdb fall back to the project's
main DSN (mongodb in dedicated mode) and fail with "Vector types are
not supported by the current database".
Pass a resolver that builds the proper DSN from the destination
project's pools per database type, mirroring the logic
`Database/Create.php` already uses on first creation. Made
`constructDatabaseDSNFromProjectDatabase` public+static so the worker
can reuse it instead of duplicating the pool-selection logic.
This is a 1.9.x regression introduced by the migration 1.10.1 -> 1.10.2
bump; affects every PR that runs MongoDB-dedicated Migrations tests.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`getDatabasesDB` used `??` to fall back from a database doc's `database`
attribute to the project DSN, but `??` only triggers on null. Migration
destinations end up with an empty-string `database` (the value is copied
from the source DB but isn't a valid DSN on the destination's pool),
which slipped past the fallback and surfaced as a 500 with
`new DSN('mysql://')` in the catch block. Use elvis so empty strings
fall back too.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The report's embedded insights subquery is capped at APP_LIMIT_SUBQUERY,
so insights past position 1000 would 404 even though they exist. Try
the embedded slice first, then fall back to a scoped direct lookup.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Chirag Aggarwal
Matej Bačo
Jake BarnbyandClaude Opus 4.7
copilot-swe-agent[bot]andabnegate
ArnabChatterjee20k
premtsd-code
Levi van Noort
Matej Bačo