mirror of
https://github.com/ModernRelay/omnigraph.git
synced 2026-06-12 01:45:14 +02:00
937fd6382d
The POST /graphs runtime-create endpoint shipped in PR 7/10 has three
unresolved high-severity bugs:
- flock-on-renamed-inode race: the YAML flock is taken on
omnigraph.yaml itself, then a temp file is renamed over it.
Cross-process writers end up locking different inodes — both
believing they hold exclusive access.
- duplicate-check outside the file lock: precheck runs against
the in-memory registry only; the locked closure does
config.graphs.insert(...) unconditionally. Concurrent same-id
POSTs can persist the loser in YAML while the in-memory registry
keeps the winner — they disagree after restart.
- best_effort_cleanup_init_artifacts deletes _schema.pg /
_schema.ir.json / __schema_state.json on any init failure. An
accidental re-init against an existing graph's URI destroys its
schema; subsequent open() fails at read_text(_schema.pg).
The correct fix is a Lance-style cluster catalog (reserve → init →
publish with recovery sidecars), parallel to the engine's existing
__manifest discipline. That work is out of scope for v0.7.0.
For now, disable runtime add/remove from the network and CLI surface.
Operators add graphs by editing omnigraph.yaml and restarting. The
GET /graphs read-only enumeration stays.
Removed:
- POST /graphs handler + router fragment + utoipa registration
- 13 post_graphs_* server tests + 3 composite POST tests +
multi_mode_app_with_real_config / post_graph helpers
- CLI omnigraph graphs create subcommand + its handler + cli.rs tests
- system_remote.rs combined list+create test trimmed to list-only
- YAML rewrite infra: rewrite_atomic[_with_modify], RewriteAtomicError,
staging_path, hash_config_file, AppState::config_hash field +
threading through new_multi and open_multi_graph_state
- fs2 dependency (verified absent from cargo tree)
- sha2/fs2 imports in config.rs (only the rewrite path used them)
- Cedar PolicyAction::GraphCreate variant + "graph_create" match arms
+ action def in Cedar schema + graph_create_action_authorizes_against_server_resource test
- GraphCreateRequest / GraphCreateResponse / GraphSchemaSpec /
GraphPolicySpec API types (only the POST handler / CLI imported them)
Kept:
- GET /graphs (read-only enumeration) and graph_list Cedar action
- omnigraph graphs list CLI subcommand
- All multi-graph startup, mode inference, cluster routes,
per-graph + server-level Cedar policies
- server_settings_drive_multi_graph_startup_end_to_end (the test
that covers operator-authored YAML + restart — the path that
survives)
- best_effort_cleanup_init_artifacts and the three init failpoints
(still reachable from CLI `omnigraph init`; preflight fix deferred
as a follow-up)
- GraphRegistry::insert and its concurrency tests — production
callers gone, but the method is the natural seam for the future
cluster-catalog work
Also fixed (transcript issue 4):
- ALWAYS_FLAT_PATHS now includes /graphs so multi-mode OpenAPI
advertises the management route correctly (was previously rewritten
to /graphs/{graph_id}/graphs)
- multi_mode_openapi_keeps_healthz_flat → renamed to
multi_mode_openapi_keeps_management_paths_flat, asserts both
/healthz and /graphs stay flat
- multi_mode_openapi_prefixes_operation_ids_with_cluster skips
/graphs in addition to /healthz
Doc fixes:
- docs/user/cli.md: graphs list example was --target http://...,
but --target is a config-graph-name lookup; corrected to --uri.
Removed the graphs create example.
- docs/user/server.md: dropped POST /graphs row, "omnigraph.yaml
ownership", and "POST /graphs body shape" sections. Added a
paragraph stating runtime add/remove is not exposed in v0.7.0.
- docs/user/policy.md: dropped graph_create action; reworded the
"Configuration" line to clarify that server-scoped rules (graph_list)
take neither branch_scope nor target_branch_scope.
- docs/releases/v0.7.0.md: rewrote release narrative — multi-graph
mode ships; runtime add/remove deferred.
- AGENTS.md: HTTP server bullet and capability matrix row updated to
reflect read-only GET /graphs and the operator-edit workflow.
- openapi.json regenerated; /graphs has only .get, no .post.
Diff: 17 files, +123 −1525 LOC.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
118 lines
3.6 KiB
Markdown
118 lines
3.6 KiB
Markdown
# CLI Guide
|
|
|
|
## Core Graph Flow
|
|
|
|
```bash
|
|
omnigraph init --schema ./schema.pg ./graph.omni
|
|
omnigraph load --data ./data.jsonl --mode overwrite ./graph.omni
|
|
omnigraph snapshot ./graph.omni --branch main --json
|
|
omnigraph read --uri ./graph.omni --query ./queries.gq --name get_person --params '{"name":"Alice"}'
|
|
omnigraph change --uri ./graph.omni --query ./queries.gq --name insert_person --params '{"name":"Mina","age":28}'
|
|
```
|
|
|
|
## Branching And Reviewable Data Flows
|
|
|
|
```bash
|
|
omnigraph branch create --uri ./graph.omni --from main feature-x
|
|
omnigraph branch list --uri ./graph.omni
|
|
omnigraph branch merge --uri ./graph.omni feature-x --into main
|
|
|
|
omnigraph ingest --data ./batch.jsonl --branch review/import-2026-04-09 ./graph.omni
|
|
omnigraph export ./graph.omni --branch main --type Person > people.jsonl
|
|
omnigraph commit list ./graph.omni --branch main --json
|
|
omnigraph commit show --uri ./graph.omni <commit-id> --json
|
|
```
|
|
|
|
## Remote Server Mode
|
|
|
|
Serve a graph:
|
|
|
|
```bash
|
|
omnigraph-server ./graph.omni --bind 127.0.0.1:8080
|
|
```
|
|
|
|
Read through the HTTP API:
|
|
|
|
```bash
|
|
omnigraph read \
|
|
--target http://127.0.0.1:8080 \
|
|
--query ./queries.gq \
|
|
--name get_person \
|
|
--params '{"name":"Alice"}'
|
|
```
|
|
|
|
If the server requires auth, set `OMNIGRAPH_SERVER_BEARER_TOKEN` on the server
|
|
and configure the matching `bearer_token_env` in `omnigraph.yaml`.
|
|
|
|
## Multi-graph servers (v0.7.0+)
|
|
|
|
Against a multi-graph server (started with `--config omnigraph.yaml` referencing a non-empty `graphs:` map), use `omnigraph graphs list` to enumerate the registered graphs:
|
|
|
|
```bash
|
|
omnigraph graphs list --uri http://server.example.com --json
|
|
```
|
|
|
|
`list` rejects local URI targets — it's for remote multi-graph servers only.
|
|
|
|
Runtime add/remove is **not** in v0.7.0. To add a graph, stop the server, add a `graphs.<id>` entry to `omnigraph.yaml`, then restart. To remove, stop the server, delete the entry, restart.
|
|
|
|
Per-graph URLs: hit a graph's cluster route from any subcommand by pointing `--uri` at it:
|
|
|
|
```bash
|
|
omnigraph read --uri http://server.example.com/graphs/beta --query ./q.gq ...
|
|
```
|
|
|
|
## Runs, Policy, And Diagnostics
|
|
|
|
```bash
|
|
omnigraph query lint --query ./queries.gq --schema ./schema.pg --json
|
|
omnigraph query check --query ./queries.gq ./graph.omni --json
|
|
|
|
omnigraph schema plan --schema ./next.pg ./graph.omni --json
|
|
omnigraph schema apply --schema ./next.pg ./graph.omni --json
|
|
omnigraph policy validate --config ./omnigraph.yaml
|
|
omnigraph policy test --config ./omnigraph.yaml
|
|
omnigraph policy explain --config ./omnigraph.yaml --actor act-alice --action read --branch main
|
|
|
|
omnigraph commit list ./graph.omni --json
|
|
omnigraph commit show --uri ./graph.omni <commit-id> --json
|
|
```
|
|
|
|
(The legacy `omnigraph run list/show/publish/abort` subcommands were removed in MR-771; mutations and loads publish atomically and the commit graph (`omnigraph commit list`) is the audit surface.)
|
|
|
|
`query lint` and `query check` are the same command surface. In v1, graph-backed
|
|
lint uses local or `s3://` graph URIs; HTTP targets are only supported when you
|
|
also pass `--schema`.
|
|
|
|
## Config
|
|
|
|
`omnigraph.yaml` lets the CLI and server share named graphs, defaults, and
|
|
query roots:
|
|
|
|
```yaml
|
|
graphs:
|
|
local:
|
|
uri: ./demo.omni
|
|
dev:
|
|
uri: http://127.0.0.1:8080
|
|
bearer_token_env: OMNIGRAPH_BEARER_TOKEN
|
|
|
|
cli:
|
|
graph: local
|
|
branch: main
|
|
|
|
query:
|
|
roots:
|
|
- queries
|
|
- .
|
|
```
|
|
|
|
The config file can also define:
|
|
|
|
- server bind defaults
|
|
- auth env files
|
|
- query aliases for common read and change commands
|
|
- `policy.file` for Cedar authorization rules
|
|
|
|
When policy is enabled, `schema apply` is authorized through the
|
|
`schema_apply` action and is typically limited to admins on protected `main`.
|