EF warning 20504 (multiple collection includes) + DEPLOYMENT.md §8.1 nested-daemon gap #77

New issue

Closed

opened 2026-08-16 09:44:19 +02:00 by matikane · 0 comments

matikane commented

2026-08-16 09:44:19 +02:00

Member

Two follow-ups from the 2026-08-16 production debugging session (doujin-manager crash-loop after the #66 non-root hardening).

Part A — EF Core warning 20504

Production logs showed Compiling a query which loads related collections for more than one collection navigation ... SingleQuery on GET /api/doujins/{id} and GET /api/variants/{id}. Two more sites compile the same way even though the log window didn't catch them: DoujinService.ListAsync (Titles + Variants) and the SearchService paged doujin query (7 collection navigations).

Fix: .AsSplitQuery() on these read-only detail/list/search queries (no global UseQuerySplittingBehavior — keep the change surgical). Tests: configure RelationalEventId.MultipleCollectionIncludeWarning to throw and assert each site passes — one test per site so removing an AsSplitQuery kills exactly its named test.

Part B — DEPLOYMENT.md §8.1 nested-daemon gap

This deployment runs umbrel → portainer dind (portainer_docker_1, dockerd at unix:///data/docker.sock, data-root /data/data) → doujin-manager. Inside dind, the docker run --rm -v <stack>_db:/data alpine chown repair can't reach the volume: no default socket, no TLS certs, volumes not under /var/lib/docker. What works: docker exec into the dind container and chown the volume directory directly:

sudo docker exec portainer_docker_1 chown -R 1654:1654 /data/data/volumes/<stack>_db/_data

Add a short paragraph covering this.

Ref trace: crash was SQLite Error 8: attempt to write a readonly database on SqliteHistoryRepository.AcquireDatabaseLockAsync — root-owned DB in a pre-#66 volume vs uid 1654; resolved live by exactly this chown.

Two follow-ups from the 2026-08-16 production debugging session (doujin-manager crash-loop after the #66 non-root hardening). **Part A — EF Core warning 20504** Production logs showed `Compiling a query which loads related collections for more than one collection navigation ... SingleQuery` on `GET /api/doujins/{id}` and `GET /api/variants/{id}`. Two more sites compile the same way even though the log window didn't catch them: `DoujinService.ListAsync` (`Titles` + `Variants`) and the `SearchService` paged doujin query (7 collection navigations). Fix: `.AsSplitQuery()` on these read-only detail/list/search queries (no global `UseQuerySplittingBehavior` — keep the change surgical). Tests: configure `RelationalEventId.MultipleCollectionIncludeWarning` to throw and assert each site passes — one test per site so removing an `AsSplitQuery` kills exactly its named test. **Part B — DEPLOYMENT.md §8.1 nested-daemon gap** This deployment runs umbrel → portainer dind (`portainer_docker_1`, dockerd at `unix:///data/docker.sock`, data-root `/data/data`) → doujin-manager. Inside dind, the `docker run --rm -v <stack>_db:/data alpine chown` repair can't reach the volume: no default socket, no TLS certs, volumes not under /var/lib/docker. What works: `docker exec` into the dind container and chown the volume directory directly: ``` sudo docker exec portainer_docker_1 chown -R 1654:1654 /data/data/volumes/<stack>_db/_data ``` Add a short paragraph covering this. Ref trace: crash was `SQLite Error 8: attempt to write a readonly database` on `SqliteHistoryRepository.AcquireDatabaseLockAsync` — root-owned DB in a pre-#66 volume vs uid 1654; resolved live by exactly this chown.

matikane referenced this issue from a pull request that will close it,

2026-08-16 09:56:32 +02:00

fix: split-query multi-collection reads + dind volume repair docs #78