The paragraph-refactor service was using OLLAMA_BASE_URL directly from
environment variables instead of using the configured AI provider from
the database. This caused "OLLAMA error" even when OpenAI was configured
in the admin interface.
Changes:
- paragraph-refactor.service.ts: Now uses getSystemConfig() and
getTagsProvider() from factory instead of direct Ollama calls
- factory.ts: Added proper error messages when API keys are missing
- .env.docker.example: Updated with new provider configuration
variables (AI_PROVIDER_TAGS, AI_PROVIDER_EMBEDDING)
This fixes the issue where AI reformulation features (Clarify, Shorten,
Improve Style) would fail with OLLAMA errors even when OpenAI was
properly configured in the admin settings.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Critical fix for production deployment on Proxmox/Docker.
Problem:
- Runtime error: Prisma Client could not locate Query Engine for "debian-openssl-1.1.x"
- Wrong binary target generated (Windows dll instead of Linux .so.node)
- Wrong OpenSSL version (3.0.x instead of 1.1.x for Debian 11)
Root cause:
- Schema.prisma didn't specify binaryTargets
- Prisma auto-detected Windows during local development
- Debian 11 (bullseye) uses OpenSSL 1.1.x, not 3.0.x
Solution:
1. Add binaryTargets to schema.prisma:
- "debian-openssl-1.1.x" for Docker/Proxmox
- "native" for local development
2. Fix Prisma folder permissions in Docker:
- RUN chown -R nextjs:nodejs /app/prisma
- Ensures Query Engine binary is readable by app user
Changes:
- prisma/schema.prisma: Add binaryTargets = ["debian-openssl-1.1.x", "native"]
- keep-notes/Dockerfile: Add chown for /app/prisma folder
Verification:
✓ libquery_engine-debian-openssl-1.1.x.so.node exists
✓ Permissions: nextjs:nodejs (readable)
✓ Prisma Client loads successfully in container
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
