21 Commits

Author SHA1 Message Date
sriram
c0601b65fe Brand Discovery-LLM Updates 2026-09-29 16:42:49 +05:30
sriram
c0489d89d6 Updates on Image search using vectors 2026-09-28 15:44:01 +05:30
sriram
fe208f4715 Image capturing Flow updates 2026-09-24 17:18:38 +05:30
sriram
f933ea10a1 Image vector to product details 2026-09-19 15:39:53 +05:30
sriram
afa0bfa743 image vector dimensionality reduction 2026-09-17 14:21:48 +05:30
sriram
9c8dbf1759 Image vector embedding 2026-09-16 16:33:39 +05:30
sriram
10b24c6348 Catalog feature updates on column fields 2026-09-08 15:18:29 +05:30
sriram
2749bee1a3 Brand Ingestion 2026-09-07 17:52:45 +05:30
sriram
164ef90b31 Automate checklist-backend updates 2026-08-31 15:32:30 +05:30
sriram
3df2dc5991 Backend upload-automation file 2026-08-31 14:59:14 +05:30
sriram
8394316907 backend store_catalog updates 2026-08-31 11:03:56 +05:30
Suriyakumarvijayanayagam
52f5d3be1d sheet upload fix 2026-08-28 11:22:53 +05:30
sriram
bbeb859d05 login passcode changes 2026-08-24 13:07:21 +05:30
sriram
7bf8dc6922 Add Dagster orchestration and reduce active brands in backend 2026-08-20 16:39:54 +05:30
sriram
1b56aae396 backend env updates and brand json files 2026-08-14 12:14:58 +05:30
Suriyakumarvijayanayagam
00216ae834 Point the docs at the real API domain, mcp.nearle.ai.in
The deployment landed on mcp.nearle.ai.in, not the mcp.catalogue.nearle.ai.in
these references were written against. Only comments, README and .env.example
are affected - nothing reads the hostname at runtime - but a wrong host in the
connection snippet is a wrong host somebody pastes into an MCP client.

API_CORS_ORIGINS is unchanged: it takes the FRONTEND's origin
(catalogue.nearle.ai.in), not the API's, so moving the API does not affect it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-13 13:29:34 +05:30
Suriyakumarvijayanayagam
e47edd2bb7 Serve the API on 3000 and 8000 at once, matching the frontend image
Dokploy routes the domain to port 3000, but the container only bound 8000, so
the proxy had nothing to talk to and the domain returned 502 with a perfectly
healthy process behind it.

The frontend image already solved this by answering on both 80 and 3000
(`listen 80; listen 3000;` in nginx.conf). Do the same here rather than swap one
guess for another: 3000 is what the platform routes to, and 8000 is what the
README, the vite dev proxy and docker-compose all target, so binding both means
the container works whichever one it is pointed at.

uvicorn's CLI takes a single --port, but Server.run() accepts pre-bound
sockets, so serve.py binds each port and hands the list to one uvicorn - no
extra worker or second process to supervise. PORT still pins a single port for
anyone who wants one; PORTS changes the pair.

A port that cannot be bound is logged and skipped rather than being fatal,
since losing one of the two should not take down a service the platform only
routes to on the other. It exits non-zero only when nothing is listening at
all, so a genuinely dead container is still reported as failed.

The healthcheck moves into the same file and passes if either port answers,
which keeps it from drifting out of sync with what is actually bound.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-13 12:38:35 +05:30
Suriyakumarvijayanayagam
2493b86ed8 Fix nutrition upload crash, persist runtime writes, serve API on its own domain
/api/upload/nutrition called json.dumps() in a module that never imported
json, so every request to it raised NameError, was swallowed by the broad
except, and came back as "500 Database import failed". Import json.

Persist the three directories the app writes to at runtime. Products added
through the UI are appended to data/seed_catalogs/*.json and retrained models
are written to app/intelligence/artifacts/*.joblib; both live inside the image,
so a redeploy silently discarded them. The paths now come from settings
(DATA_DIR / SEED_CATALOG_DIR / MODEL_ARTIFACTS_DIR) so a volume can be mounted
on them, and catalog_engine.save_catalog resolves against DATA_DIR instead of
a working-directory-relative "data/", which landed somewhere different
depending on where the process was started from.

Mounting those volumes would otherwise have made things worse: Docker seeds a
named volume from the image on first use, but a bind mount starts empty and
just hides what the image shipped. A bind mount on /app/data would have left
the API with no seed catalogs, so the next product added would write a JSON
file containing only that product. The image now keeps pristine copies at
/app/.bundled, and restore_bundled_assets() tops up whatever a freshly mounted
directory is missing at startup without overwriting anything already there.

Configure CORS for the split-domain deployment: the React app is served from
catalogue.nearle.ai.in and calls the API on mcp.catalogue.nearle.ai.in, so the
frontend origin has to be in API_CORS_ORIGINS. A wrong list fails only in the
browser while the server logs a healthy 200, so the effective origins are now
logged at startup with a warning when they are localhost-only.

Fix FRONTEND_DIST, which looked for a sibling "frontend/" directory that is
actually named "catalogue_frontend/", so the single-port unified-serving branch
could never activate even with a build sitting next to it.

Rebuild the Dockerfile on the frontend's multi-stage pattern: dependencies
resolve into a venv in a build stage, the runtime stage copies only that.
Adds PYTHONUNBUFFERED so startup errors reach Dokploy's log pane, a liveness
HEALTHCHECK (/api/health answers 200 even when Postgres is down, so a database
blip cannot restart-loop the container), and an overridable PORT. The CMD execs
uvicorn so SIGTERM reaches it rather than the sh wrapper.

Add "from __future__ import annotations" to ollama_service and image_search,
which used PEP 604 unions in runtime-evaluated signatures and so could not be
imported below Python 3.10.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-13 12:30:45 +05:30
sriram
b8d93fbbf2 Updated backend auth settings 2026-08-12 18:10:25 +05:30
sriram
ac8cfacbc9 Updated backend 2026-08-12 16:37:28 +05:30
sriram
c2af4556c6 updates on the backend 2026-08-11 19:16:01 +05:30