https://sonarly.com/issue/17951?type=bug
The `MessageChannelDataAccessService.findMany` method passes a `deletedAt: IsNull()` filter on the `connectedAccount` relation to the core TypeORM repository, but the new `ConnectedAccountEntity` lacks a `deletedAt` column, causing an `EntityPropertyNotFoundError`.
Fix: Three changes in `MessageChannelDataAccessService`:
**1. `toCoreWhere` — always strip `connectedAccount` from the where clause**
Previously, after extracting `accountOwnerId`, any remaining `connectedAccount` properties (like `deletedAt: IsNull()`) were kept as a nested relation filter. But `ConnectedAccountEntity` in the core schema doesn't have `deletedAt` (or `accountOwnerId`), so TypeORM throws `EntityPropertyNotFoundError`. The fix unconditionally deletes `coreWhere.connectedAccount` after resolving `accountOwnerId` to `connectedAccountId`.
**2. `find` — route through `toCoreWhere`**
The `find` method was spreading `where` directly into the core query without processing `connectedAccount` filters. This would fail for any caller passing `connectedAccount` relation filters (e.g., the blocklist reimport job). Now routes through `toCoreWhere` like the other methods.
**3. `findMany` — apply relation-stripping pattern from `findOne`**
The `findOne` method already correctly handles the migrated path: it strips `connectedAccount` and `messageFolders` from `relations`, strips `connectedAccount` from `select`, queries the core repository, then resolves connected accounts and message folders separately via their data access services. The `findMany` method was missing this logic — it passed all options (including `relations: ['connectedAccount']` and nested `connectedAccount` select/where) directly to the core repository. The fix applies the identical pattern, with the optimization of batch-loading connected accounts via a Map to avoid N+1 queries.
Sonarly Claude Code
fe2c79ceb5