- Ya
- 13 Agosti 2026, 00:38 UTC
- Mwandishi
- Kamo
- Ahadi ya
- f380da9
The datasource still named port 26257. That is the retired CockroachDB, which is still running and still answering, so a run against it succeeds completely and reaches nothing: ACCOUNT_HISTORY was created in a database no service reads, while the SecurityService deployment that queries it went live against Yugabyte without it. Now 5433, the YSQL port the deployed services use. Re-run and verified — account_history and its six indexes exist in Yugabyte. PostgreSQLDialect stays pinned, and on a real PostgreSQL it is simply correct rather than a workaround: the run dropped from 22 minutes to 14 and from 48 DDL errors to 12, all twelve inert and documented where the setting is. `mvn test` was running the entire migration suite against production. A leftover Spring Initializr scaffold — **************** a bare contextLoads() in a package belonging to no one — booted the whole app, which in this module means ddl-auto against prod (446 ALTER attempts) followed by every CommandLineRunner, SchemaCleanupRunner issuing live UPDATEs and ALTERs, and **************** dropping a unique index. Anyone running the test suite migrated production without knowing, and that is why it took twenty minutes. Three sibling test classes already warned about this in their javadoc; comments do not fail builds, so NoSpringContextInTestsTest does. The suite is now 8 seconds and issues no DDL at all. EmailTemplateSeedRunnerTest's two failures were stale expectations, not a bug: the runner deliberately re-saves SYSTEM rows so corrected canonical subjects and HTML reach the database, and both tests still forbade the write. They now assert what it is for — the SYSTEM row is refreshed from canonical, and an org's own copy is left alone because that org may have edited it.