Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Ajith66310/task-manager-full/llms.txt

Use this file to discover all available pages before exploring further.

Most TaskFlow issues fall into a small set of categories: containers that fail to start because environment variables are missing or incorrect, connectivity problems caused by mismatched service names, and authentication failures from misaligned secrets across services. The sections below cover each common failure with specific commands to identify the cause and steps to resolve it.
When one or more containers exit immediately after startup or cycle through a restart loop, start by checking the overall stack state:
docker-compose ps
Any service showing Exit or Restarting has a startup failure. Identify which service is affected, then stream its logs to find the error:
docker-compose logs -f <service>
Common causes include missing .env files, a required dependent service that hasn’t finished starting, or an invalid environment variable value. Also confirm that Docker Desktop is running before starting the stack — all docker-compose commands fail silently or with a connection error if the Docker daemon is not active.
If user-service or task-service logs show a MongoDB connection error, verify that the MONGO_URI in each service’s .env file uses the correct Docker Compose service name — not localhost.Inside the Compose network, the correct connection strings are:
# user-service/.env
MONGO_URI=mongodb://mongo-user:27017/TaskManagerUser

# task-service/.env
MONGO_URI=mongodb://mongo-task:27017/TaskManagerTask
Using localhost instead of the service name (mongo-user or mongo-task) causes a connection refused error because localhost inside a container refers to that container itself, not the MongoDB container.After correcting the URI, rebuild the affected service:
docker-compose stop user-service
docker-compose rm -f user-service
docker-compose up -d --build user-service
Also confirm both MongoDB containers are healthy before the services that depend on them start:
docker-compose ps
task_manager_mongo_user and task_manager_mongo_task should both show Up before user-service and task-service are started.
Token verification failures — typically appearing as 401 Unauthorized or JsonWebTokenError: invalid signature — are almost always caused by a mismatch between the JWT_SECRET values in user-service and task-service.The user service signs tokens with its JWT_SECRET. The task service verifies those same tokens using its own JWT_SECRET. If the two values differ, every authenticated request to task-service will be rejected.Open both .env files and confirm the JWT_SECRET values are identical:
# user-service/.env
JWT_SECRET=your_shared_secret

# task-service/.env
JWT_SECRET=your_shared_secret
After correcting either file, rebuild both services so they pick up the updated environment:
docker-compose stop user-service task-service
docker-compose rm -f user-service task-service
docker-compose up -d --build user-service task-service
The notification service uses the EmailJS API to send automated email alerts. If emails are not being delivered, check that all four required environment variables are present and correct in notification-service/.env:
EMAILJS_PRIVATE_KEY=your_emailjs_private_key
EMAILJS_PUBLIC_KEY=your_emailjs_public_key
EMAILJS_SERVICE_ID=your_emailjs_service_id
EMAILJS_TEMPLATE_ID=your_emailjs_template_id
A missing or incorrect key causes the EmailJS client to return an error that is visible in the service logs. Stream the notification service logs while triggering an action that should send an email:
docker-compose logs -f notification-service
Also confirm the notification service itself is running on port 5003:
docker-compose ps
task_manager_notification_service should show Up and port 5003 should be listed. If the container has exited, rebuild it after correcting the .env file:
docker-compose stop notification-service
docker-compose rm -f notification-service
docker-compose up -d --build notification-service
A user who has registered but has not been verified by an admin cannot create tasks. The isVerified field on the user record must be set to true before task creation is permitted.To verify a user, an admin must call the verify endpoint with the user’s ID:
PATCH /api/admin/users/:id/verify
This request must include a valid admin JWT in the Authorization header. The admin account is created automatically from the ADMIN_EMAIL and ADMIN_PASSWORD values in user-service/.env when the service starts.To confirm whether a specific user is verified, query the user record via the admin API or check the user-service logs for verification activity. Once isVerified is true on the user’s record, task creation will succeed.
If the frontend loads but all API requests fail with a network error or CORS rejection, the VITE_API_URL environment variable was likely not set correctly before the frontend container was built.Both frontend services must have VITE_API_URL pointing to the API Gateway:
# task-manager-user-frontend/.env
VITE_API_URL=http://localhost:5000/api

# task-manager-frontend/.env
VITE_API_URL=http://localhost:5000/api
Because Vite bakes environment variables into the static bundle at build time, changing a .env file after the container image has already been built has no effect. You must rebuild the frontend container after any .env change:
docker-compose stop user-frontend
docker-compose rm -f user-frontend
docker-compose up -d --build user-frontend
Repeat for admin-frontend if the admin dashboard is also affected.
TaskFlow occupies the following ports on your host machine:
PortService
5000api-gateway
5001user-service
5002task-service
5003notification-service
3000admin-frontend
5173user-frontend
27018mongo-user
27019mongo-task
If any of these ports is already in use when you run docker-compose up, the container for that service will fail to start with a port is already allocated error. Identify the conflicting process and stop it before starting the TaskFlow stack.On macOS or Linux:
lsof -i :<port>
On Windows (PowerShell):
netstat -ano | findstr :<port>
Common conflicts are port 3000 (used by many local development servers), port 27017 or 27018 (a locally installed MongoDB instance), and port 5173 (another Vite dev server).

​
Complete reset

If the stack is in a broken state and individual fixes have not resolved the issue, a full teardown and rebuild restores it to a clean starting point.
Running docker-compose down -v permanently deletes the mongo_user_data and mongo_task_data Docker volumes. All user records and task data stored in the database are destroyed and cannot be recovered. Only proceed if you are comfortable losing all local data.
Stop all containers, remove networks, and delete persistent volumes: 
docker-compose down -v
Rebuild every image from source and start the full stack: 
docker-compose up --build -d
Verify all 8 containers are running after the rebuild completes: 
docker-compose ps
After a full reset, re-populate any data that was removed and confirm the admin account credentials in user-service/.env match the values you intend to use — the createDefaultAdmin function in user-service/server.js re-creates the admin user from those values on every fresh startup.

Build docs developers (and LLMs) love

Get started for freeTalk to us