chore: sync cognee-frontend from SaaS repo [CLO-381] - #4867
chore: sync cognee-frontend from SaaS repo [CLO-381]#4867goran-radonic wants to merge 8 commits into
Conversation
Automated sync from topoteretes/cognee-saas. Source commit: 249459fe9d8dd96f677cd078066a766dc31ce62e
The last sync from the SaaS repo added a "prepare": "node scripts/setup-git-hooks.js" script to cognee-frontend/package.json, but scripts/setup-git-hooks.js never existed in this public repo. npm runs "prepare" on every install, so npm ci now fails with MODULE_NOT_FOUND anywhere it runs clean, including the "Build Cognee UI Docker Image" CI job on PR #4867. Git-hooks setup is SaaS-team tooling with no OSS counterpart, so drop the script reference instead of trying to port the file over.
The latest sync from the SaaS repo dropped "output: standalone" from next.config.ts, silently reverting COG-6319 (#4847). Without it, `next build` produces no .next/standalone directory, so the Dockerfile's runner stage has nothing to COPY and the "Build Cognee UI Docker Image" CI job fails on PR #4867.
The latest sync from the SaaS repo dropped src/modules/config/* and src/app/api/runtime-config/route.ts (COG-6343, #4821), and layout.tsx lost its RuntimeConfigScript + force-dynamic wiring. Without these, a published cognee/cognee-ui image bakes in whatever COGNEE_BACKEND_URL was set at build time and ignores the one it's actually run with — the entire point of shipping one prebuilt image. Restored the files verbatim from 989e5ce (the last commit where they existed) and re-wired layout.tsx. Verified against a real `docker build` + `docker run`, matching every assertion in frontend_docker_build_test.yml: /local-login and /api/runtime-config both carry the runtime COGNEE_BACKEND_URL, and a malformed URL still makes the container refuse to start and name the variable.
|
An automated sync that claims to "restore runtime backend URL config" while systematically deleting it — the confidence of a script that never reads its own commit messages. 🤖 🔴 2 blockers, 1 major — changes requested
See inline comments for details. |
Follow-up to b0c7847: an adversarial review found the runtime-config restore had covered 3 of 10 reverted call sites, and turned up three regressions from the same sync that no reviewer had flagged. - api/visualize and api/local-signout still read the build-time NEXT_PUBLIC_LOCAL_API_URL, so on any non-default backend the mindmap fetched from the wrong host and sign-out silently left the backend session alive (the route's catch swallowed it and still redirected). Both now use getServerBackendUrl(), which also gives that function real callers again. Verified with two listeners behind a container: every request lands on COGNEE_BACKEND_URL's port, none on the build-time one. - isOwner was permanently false: useTenant() derives it from UserContext's availableTenants, the cloud UserProvider that fills that list is never mounted in local mode, and the sync deleted LocalProvider's `isOwner: true`. Every Connect button on the Data Sources cards rendered inert. LocalProvider now supplies the local workspace as an owned tenant; added a test that fails without it. - getDatasets and useChat regained trailing slashes that 4c8ed2d removed for triggering cross-origin 307s that broke session auth. - npm test pointed at a red suite: d3's ESM-only packages were never transformed, and missing clearMocks leaked call counts between tests. next/jest only appends to transformIgnorePatterns and its own blanket node_modules entry wins, so the resolved config is widened after the fact rather than through transpilePackages, which would change the production build to fix a test problem. 49 suites / 481 tests green, from 42 / 416. Also drops two dead build-time URL constants (getLocalUser, ApiKeysPage) that 989e5ce had already removed for the same reason.
|
An adversarial review that fixes ten call sites but doesn't check if their imports still resolve — chef's kiss levels of irony. 🎭 🔴 1 blocker — changes requested
See inline comments for details. |
The sync dropped "server-only" from package.json and the lockfile, but src/modules/config/serverRuntimeConfig.ts still imports it. It was added deliberately in COG-6482 (b4343aa) to make the server-side guard on COGNEE_BACKEND_URL explicit, so a client component importing that module fails loudly instead of silently reading undefined and falling back to localhost. Nothing is visibly broken today: Next resolves the bare specifier through its own alias (webpack-config.js matches /^server-only$/ against next/dist/compiled/server-only), so the image builds and both route handlers work. That is an implementation detail of Next, not a contract, and it is the wrong thing to leave a deliberate guard resting on.
|
Five fix commits to repair a sync, and the "adversarial review" still missed three routes with the exact bug it just fixed — clearly even the adversary got tired after 26k lines. 🔴 3 blockers, 1 minor — changes requested
See inline comments for details. |
Four more files the sync reverted, same family as c81c093. The three schema proxy routes had their getServerBackendUrl() call replaced by a build-time NEXT_PUBLIC_LOCAL_API_URL constant, so they would fetch from whatever host was baked in at build time rather than the container's COGNEE_BACKEND_URL. All three are now byte-identical to 989e5ce, and no hardcoded fallback is left anywhere under src. Those three are currently unreachable: the sync deleted the schema page, and getSchemaInventory calls the backend directly rather than through the proxy. Rewired rather than deleted because the page still exists upstream, so deleting them now would hand a later sync's page a 404. instrumentation.ts was gutted to an empty register(), losing the startup check that surfaces a broken COGNEE_BACKEND_URL in the first lines of the log. The published image already refuses to boot on one via docker-entrypoint.sh; this is what covers `next start` and `cognee-cli -ui`, where killing the process is not the app's call. Verified in a container: all five proxy routes issue their requests against the runtime host and none against the build-time one, and the startup check logs on a malformed URL while staying silent on a valid one.
|
A frontend sync that accidentally shipped backend migration changes — and those changes disable the safeguard preventing database corruption on transient connection failures. 🎭 🔴 2 blockers — changes requested
Backend changes in a frontend sync PR suggest the sync script grabbed more than intended. The migration probe change is high-risk: a populated database that's temporarily unreachable (server still starting, credential rotation, network hiccup) will now be treated as empty, triggering See inline attempt above (GitHub API can't surface 349-file diffs for inline comments). Key evidence:
|
Automated frontend sync
This PR was auto-generated by the
sync-frontend-to-publicworkflowin the SaaS repo (tracking issue: CLO-381).
Source commit: https://github.com/topoteretes/cognee-saas/commit/249459fe9d8dd96f677cd078066a766dc31ce62e
What changed: Shared frontend code (routes, components, modules)
was updated in the SaaS repo and synced to
cognee-frontend/viascripts/sync-to-public.sh.Cloud-only logic (Auth0, Stripe, Segment, billing/tenant backends) is
excluded; public stubs replace private module dependencies so shared
UI compiles and degrades gracefully in local mode.
Verified by the workflow before this PR was opened:
@/import resolves (verify-public-imports.js)package-lock.jsonregenerated to match the strippedpackage.jsonnpm ci && tsc --noEmitpasses on the synced outputReview checklist
npm install && npm run devworks incognee-frontend/cognee -uilaunches the updated frontend