/drasi

Validation bundle

Use this bundle for release gates, post-deploy proof, synthetic changes, acceptance checks, and evidence collection.

Validation principle

A Drasi deployment is successful only when a source change produces the expected query result and the expected reaction side effect.

Infrastructure success, resource creation, and healthy endpoints are necessary but not sufficient.

Minimum validation chain

1. Runtime health is confirmed.
2. Source is available.
3. Query is active and has the expected result contract.
4. Reaction is healthy and subscribed to the expected query.
5. A controlled source change occurs.
6. Query result changes as expected.
7. Reaction emits or performs the expected downstream side effect.
8. Logs and metrics show no hidden errors.
9. Cleanup or rollback path is known.

Drasi Server validation

Use the live OpenAPI for exact route shapes, then validate:

curl -fsS "$DRASI_BASE_URL/health"
curl -fsS "$DRASI_BASE_URL/api/v1/openapi.json" | jq '.openapi // .swagger'
curl -fsS "$DRASI_BASE_URL/api/v1/sources" | jq '.'
curl -fsS "$DRASI_BASE_URL/api/v1/queries" | jq '.'
curl -fsS "$DRASI_BASE_URL/api/v1/reactions" | jq '.'

Then apply or call the intended API flow and verify the result endpoint or downstream reaction target.

Drasi for Kubernetes validation

drasi list source -n "$DRASI_NAMESPACE"
drasi wait source "$SOURCE_NAME" -n "$DRASI_NAMESPACE" -t 120
drasi list query -n "$DRASI_NAMESPACE"
drasi describe query "$QUERY_NAME" -n "$DRASI_NAMESPACE"
drasi list reaction -n "$DRASI_NAMESPACE"
drasi describe reaction "$REACTION_NAME" -n "$DRASI_NAMESPACE"

Then trigger a known source change and verify the expected result and reaction.

Synthetic test design

Use small, reversible test data:

• One insert/add event.
• One update event.
• One delete/remove event.
• One non-matching event that should not trigger a result.
• One edge case for null, missing, late, or duplicate values if relevant.

For production-like environments, ensure test data is labelled, reversible, and excluded from business metrics where needed.

Per-provider test-data preparation

"Trigger a known source change" must be defined concretely per provider. Use the smallest, reversible change that exercises the full source → query → reaction chain. Always capture the trigger command and the expected query/reaction observation in the acceptance evidence record.

PostgreSQL Source

# Connect with a test user (least-privilege, not the Drasi capture user)
psql "$PG_URL" -c "INSERT INTO public.app_users(id, email, status) VALUES (gen_random_uuid(), 'qa+$(date +%s)@example.test', 'active');"
# Expected: query result includes the new row within p95 ≤ 10 s; reaction logs/webhook fires.
# Clean up
psql "$PG_URL" -c "DELETE FROM public.app_users WHERE email LIKE 'qa+%@example.test';"

SQL Server Source

INSERT INTO dbo.Orders(OrderId, CustomerId, Amount, Status)
VALUES (NEWID(), 'qa-test', 0, 'Test');
-- After verification:
DELETE FROM dbo.Orders WHERE CustomerId = 'qa-test';

Kubernetes Source

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: ConfigMap
metadata:
  name: drasi-validation-trigger
  namespace: <test-ns>
  labels:
    drasi.io/test: validation
data:
  trigger: "{{date}}"
YAML
# Verify, then delete:
kubectl -n <test-ns> delete configmap drasi-validation-trigger

Drasi Server with kind: mock Source

The mock source emits synthetic events on its own interval. To prove the chain, simply confirm that curl http://localhost:8080/api/v1/queries/<query-id>/results returns rows matching the query predicate within the configured intervalMs window.

Dataverse Source

Use a dedicated test record in the target entity (e.g., a Test contact) and update a non-PII field such as description. Avoid using a real customer record.

Acceptance evidence to capture

For each validation run, record:

• The trigger command, including timestamp.
• Source ingest lag from logs/metrics at the time of trigger.
• Query result diff (before/after).
• Reaction observation (log line, webhook log, Event Grid delivery receipt, SignalR client message, MCP notifications/resources/updated event).
• Cleanup command and confirmation that source/query/reaction state returned to baseline.

Save this in templates/drasi-acceptance-evidence.md for the release.

Acceptance evidence template

Runtime: <Drasi Server | Drasi for Kubernetes | drasi-lib>
Version: <server/platform/cli/image digest>
Source: <name>, status <status>, evidence <command/output/link>
Query: <name>, status <status>, expected fields <fields>
Reaction: <name>, status <status>, downstream target <target>
Test change: <insert/update/delete details>
Observed query result: <summary>
Observed reaction effect: <summary>
Security exposure: <private/authenticated/public with controls>
Rollback path: <summary>
Residual risk: <summary>

Failure handling

If validation fails:

1. Do not mark the deployment successful.
2. Preserve resources and logs unless cleanup is safer.
3. Identify the first broken dependency in the chain.
4. Route to operations, then the specific resource bundle.
5. If state appears corrupted or reset is proposed, route to recovery.

Unit-test layer (per artefact)

The chain above proves integration and end-to-end behaviour. Each artefact also has a narrower unit-test surface that should run before integration:

• ContinuousQuery (Cypher / GQL) - replay a recorded event sequence offline against the query definition, then assert the result-contract shape and per-row values. Use the result-contract examples in bundles/continuous-queries/guide.md as the assertion fixture. Confirm at the current release whether a Drasi CLI offline query-runner exists; if not, drive replay through drasi-lib (see below) or a captured-event harness.
• Reaction (HTTP / Event Grid / SignalR / MCP / gRPC) - table-drive the expected request shape from sample query-result events; assert HMAC/auth headers and the idempotency-key field your reaction is configured to emit; mock the downstream and assert exactly-once-from-our-side delivery (no duplicate POST on retry within the idempotency window). See bundles/reactions/guide.md for per-kind request shapes.
• drasi-lib embedded Rust - standard cargo test against the in-process Drasi runtime with a fixed test source feeding canned events; assert query results and reaction callbacks inline. See bundles/drasi-lib/guide.md.
• Per-Source CDC adapters - not unit-tested inside Drasi itself; covered by integration tests against a real DB instance with a captured replication-slot / CDC fixture. Treat these as integration tests in CI, not unit tests.

Unit tests must run on every PR; integration and end-to-end validation gate promotion (see bundles/delivery/guide.md).