Repository navigation
feat: ship secure web workbench - #18
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 20ff97afbf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| setAuthState('authenticated') | ||
| setAuthState('unavailable') |
There was a problem hiding this comment.
Route auth failures to the login page
In team mode, an unauthenticated /api/v1/health response is { error: 'API key required...' }, and request() throws that body text rather than HTTP 401, so the regex above does not match. With this new fallback, first-time team-mode users are sent to the “server unavailable” screen instead of LoginPage, leaving no way to enter an API key from the web UI.
Useful? React with 👍 / 👎.
| - "${OPENDOCUMENTS_PORT:-3333}:3000" | ||
| volumes: | ||
| - opendocuments-demo-data:/data | ||
| - ./docker/demo/opendocuments.config.ts:/app/opendocuments.config.ts:ro |
There was a problem hiding this comment.
Commit the demo config before mounting it
The documented demo command mounts ./docker/demo/opendocuments.config.ts, but that file is not present in docker/demo or elsewhere in the repo (rg opendocuments.config only finds this mount/docs). A fresh docker compose -f docker-compose.demo.yml up --build will therefore fail the bind mount or create a directory at /app/opendocuments.config.ts, after which config loading fails, making the new demo compose file unusable as checked in.
Useful? React with 👍 / 👎.
| if (!options.force && !store.hasContentChanged(existing.id, contentHash)) { | ||
| return { documentId: existing.id, chunks: existing.chunk_count ?? 0, status: 'skipped' } |
There was a problem hiding this comment.
Avoid skipping errored forced reindexes
When --reindex now calls ingest(..., { force: true }) on unchanged content and that reindex fails before updateContentHash, the old content_hash is left in place while the row is marked error. A later normal indexing run of the same file hits this skip path because the hash still matches, so the errored document is never restored to indexed and remains filtered out of search results.
Useful? React with 👍 / 👎.
Summary
Review fixes
/healthzliveness endpoint and update Docker probesdocument:writefor collection mutation routesValidation
npm run build— 26/26 tasks passednpm run typecheck— 29/29 tasks passednpm run lint— 29/29 tasks passednpm run test— 51/51 tasks passednpx changeset statuspassedgit diff --checkpassed20ff97a