mirror of https://github.com/ModernRelay/omnigraph.git synced 2026-06-12 01:45:14 +02:00

Ragnor Comerford d11c18fb27

mr-668: composite e2e tests, race fix, v0.7.0 release (PR 9/10)

PR 9 — the final integration PR for MR-668 multi-graph server work.
Closes the v0.7.0 release.

Composite lifecycle tests (closes gaps flagged in PR 7's coverage
review):
  - `multi_graph_lifecycle_post_query_restart_persistence` — POST a
    graph, query it via cluster route, reload the config from disk
    and confirm `load_server_settings` sees the rewritten YAML.
    Validates the "restart resolves orphans" failure-mode story.
  - `per_graph_policy_enforced_on_post_created_graph` — POST a graph
    with a per-graph policy attached, then send authenticated read
    and change requests. Per-graph Cedar enforcement fires correctly
    on a POST-created graph (engine-layer policy reinstalled via
    `Omnigraph::with_policy` inside the create flow).
  - `concurrent_post_graphs_distinct_ids_all_succeed` — 4 concurrent
    POSTs with distinct graph_ids all return 201. Caught a real
    race in `rewrite_atomic` (see below).

Race fix — `rewrite_atomic_with_modify`:

The first composite test surfaced a real bug. The old
`rewrite_atomic(path, new_config, expected_hash)` captured the
baseline hash OUTSIDE the flock, then called rewrite_atomic which
re-acquired it inside. Under concurrent writers:

  - POST A: captures baseline H0, calls rewrite_atomic.
  - POST B: captures baseline H0 too (before A's update lands).
  - A: acquires flock, on-disk == H0, writes H1, releases.
  - A: updates baseline H0 → H1.
  - B: tries to acquire flock — waits.
  - B: acquires flock. On-disk is now H1. Expected (captured
       before A finished) is H0. MISMATCH → spurious Drift error.

Worse: even if the timing happens to align, B's `updated` config
was constructed from BYTES read before the flock. B writes a config
that doesn't include A's new graph — silent data loss.

The fix: new `config::rewrite_atomic_with_modify(path, baseline,
modify)` takes a closure. Inside the flock + baseline mutex:
  1. Read on-disk bytes, hash, compare to baseline.
  2. Parse on-disk YAML.
  3. Call `modify(parsed)` to produce the new config — receives
     fresh on-disk state, returns the modification.
  4. Serialize + write + fsync + rename + update baseline.

Everything is read-modify-write under the same critical section.
Concurrent writers serialize cleanly. Test confirmed this is no
longer a race.

The old `rewrite_atomic(path, new_config, expected_hash)` API stays
for tests that don't need the read-modify-write shape; the POST
handler switches to the new shape.

Version bump v0.6.0 → v0.7.0:
  - All 5 `crates/*/Cargo.toml` (compiler, engine, policy, cli, server)
    plus their inter-crate `path` dep version constraints.
  - `Cargo.lock` regenerated by `cargo build --workspace`.
  - `AGENTS.md` "Version surveyed" line, capability matrix HTTP-server
    row updated to mention multi-graph + cluster routes + atomic YAML
    rewrite.
  - `openapi.json` regenerated.

Docs:
  - `docs/releases/v0.7.0.md` (new) — release notes with breaking
    changes, new features, deferred items (DELETE, `delete_prefix`,
    actor forwarding), and the single→multi migration recipe.
  - `docs/user/server.md` — substantial section additions for the
    two modes, mode inference, cluster endpoint table, management
    endpoints, `omnigraph.yaml` ownership contract, `POST /graphs`
    body shape + status codes.
  - `docs/user/cli.md` — `omnigraph graphs list/create` section,
    deferred-DELETE note.
  - `docs/user/policy.md` — server-scoped Cedar actions
    (`graph_create`, `graph_list`), per-graph vs server-level policy
    composition, example server-level policy.

Workspace test pass: 573 tests green across all crates. Zero
failures. MR-731 spoof regression still pinned and passing across
the entire 10-PR series.

This commit closes MR-668. v0.7.0 is ready for tagging.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-25 21:32:49 +02:00

3.9 KiB

Raw Blame History

CLI Guide

Core Graph Flow

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

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:

omnigraph-server ./graph.omni --bind 127.0.0.1:8080

Read through the HTTP API:

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 to enumerate and create graphs:

# List
omnigraph graphs list --target http://server.example.com --json

# Create
omnigraph graphs create \
  --target http://server.example.com \
  --graph-id beta \
  --graph-uri /data/beta.omni \
  --schema schema.pg \
  --policy-file ./policies/beta.yaml   # optional

The CLI reads --schema from the local disk and inlines the contents as schema.source in the request body. Both subcommands reject local URI targets — they're for remote multi-graph servers only.

omnigraph graphs delete is not in v0.7.0. To remove a graph, stop the server, edit omnigraph.yaml, restart.

Per-graph URLs: once a graph exists, hit its cluster route from any subcommand by pointing --uri at it:

omnigraph read --uri http://server.example.com/graphs/beta --query ./q.gq ...

Runs, Policy, And Diagnostics

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:

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.

3.9 KiB Raw Blame History