@claude — this supersedes/expands the two narrower issues I just filed (please dedupe). Goal: generate keywords with AI and persist them to Mongo in mendys-prod. Two root causes, and I want the process fixed so future repos don't repeat it — not just a one-off patch.
A) Mongo role provisioning is incomplete — SYSTEMIC
The mendys role authenticates (authSource admin) but has no privileges on the database the app uses (robot_catalog). Backend logs:
Error finding documents in keywords: not authorized on robot_catalog ... 'code': 13, 'codeName': 'Unauthorized'
Error counting documents in keywords: not authorized on robot_catalog ... 'code': 13
createIndexes "robots": not authorized on robot_catalog ... 'code': 13
So GET /keywords/ returns 200 with an EMPTY list (error swallowed) and all writes fail. The db-bootstrap/service-DB reconciliation (your #228/#229) creates the role but does not grant it readWrite on the app's actual Mongo database. This will hit every repo onboarded this way.
Asks (process-level, not just mendys):
- Make the service-DB provisioning take each service's Mongo database name as an explicit parameter and ALWAYS grant the service role
readWrite on that exact DB (apply the same completeness check to Postgres/Neo4j: role must be granted on the DB it's meant to use, with a post-provision verification step that fails loudly if a role can auth but can't read/write its DB).
- Document the contract: a repo declares its DB name → provisioning guarantees the role is authorized on it.
- For MendysRobotics now: either grant
mendys readWrite on robot_catalog, OR — if the platform convention is a service-named DB — provision/grant on a mendys database and tell me the canonical name; I will set MONGODB_DATABASE on our side to match (currently robot_catalog, authSource admin). Whichever you standardize, tell me the DB name.
B) No egress to the LLM providers
AI keyword generation 500s because the backend can't reach the model APIs:
LLM API error: Connection error.
"POST /keywords/generate HTTP/1.1" 500
OPENAI_API_KEY is present (SealedSecret) — the pod just has no outbound HTTPS to the provider. Our AI features use both OpenAI and Anthropic.
Ask (reusable): allow egress from app namespaces (mendys-prod now; ideally a reusable NetworkPolicy/egress pattern applicable to all product namespaces) to api.openai.com:443 and api.anthropic.com:443. If egress must go through a sanctioned proxy, tell me the env vars (HTTPS_PROXY / provider base URL) to set on the backend + consumers.
Verification / done-criteria
After your change: POST /keywords/generate returns 200 with generated keywords, POST /keywords/generate/batch persists them, and GET /keywords/ returns them (non-empty) in mendys-prod. Please open the PR(s) and reply with the canonical Mongo DB name + egress confirmation. DONE:/BLOCKED:.
@claude — this supersedes/expands the two narrower issues I just filed (please dedupe). Goal: generate keywords with AI and persist them to Mongo in mendys-prod. Two root causes, and I want the process fixed so future repos don't repeat it — not just a one-off patch.
A) Mongo role provisioning is incomplete — SYSTEMIC
The
mendysrole authenticates (authSourceadmin) but has no privileges on the database the app uses (robot_catalog). Backend logs:So
GET /keywords/returns 200 with an EMPTY list (error swallowed) and all writes fail. The db-bootstrap/service-DB reconciliation (your #228/#229) creates the role but does not grant itreadWriteon the app's actual Mongo database. This will hit every repo onboarded this way.Asks (process-level, not just mendys):
readWriteon that exact DB (apply the same completeness check to Postgres/Neo4j: role must be granted on the DB it's meant to use, with a post-provision verification step that fails loudly if a role can auth but can't read/write its DB).mendysreadWriteonrobot_catalog, OR — if the platform convention is a service-named DB — provision/grant on amendysdatabase and tell me the canonical name; I will setMONGODB_DATABASEon our side to match (currentlyrobot_catalog, authSourceadmin). Whichever you standardize, tell me the DB name.B) No egress to the LLM providers
AI keyword generation 500s because the backend can't reach the model APIs:
OPENAI_API_KEY is present (SealedSecret) — the pod just has no outbound HTTPS to the provider. Our AI features use both OpenAI and Anthropic.
Ask (reusable): allow egress from app namespaces (mendys-prod now; ideally a reusable NetworkPolicy/egress pattern applicable to all product namespaces) to
api.openai.com:443andapi.anthropic.com:443. If egress must go through a sanctioned proxy, tell me the env vars (HTTPS_PROXY / provider base URL) to set on the backend + consumers.Verification / done-criteria
After your change:
POST /keywords/generatereturns 200 with generated keywords,POST /keywords/generate/batchpersists them, andGET /keywords/returns them (non-empty) in mendys-prod. Please open the PR(s) and reply with the canonical Mongo DB name + egress confirmation. DONE:/BLOCKED:.