feat(n8n): add scheduled quality-scan workflow
The original docs described two n8n workflows but the repository only ever shipped one (return-processing); the sketched second workflow (knowledge sync) depends on RAGcore, which isn't connected here, so it stays deferred. Add POST /api/v1/integrations/n8n/scheduled-scan (X-Service-Token protected, same pattern as the return callback), calling the same run_scan() the manual "Run quality scan" UI action uses and recording a service-actor data_quality_scan_run audit event. run_scan() already only creates an issue for a condition without one open, so overlapping triggers do no duplicate domain work. n8n/mobilityops-scheduled-quality-scan.json (hourly schedule + manual test trigger, both feeding the same HTTP call) ships "active": false so it can't fire anywhere until deliberately published. Verified live against the local n8n instance via the Manual test trigger: full green execution, and the resulting data_quality_scan_run audit event (actor_type=service, actor_label="n8n scheduled scan") confirms the real round trip, not just a contract test. deploy/unraid/setup-scheduled-scan.sh mirrors the existing return-workflow publish script for the shared Unraid n8n.
This commit is contained in:
@@ -18,7 +18,34 @@ Steps:
|
||||
|
||||
The starter export is `n8n/mobilityops-return-processing.json`. Claude may correct its credentials and callback route but must preserve idempotency.
|
||||
|
||||
## Optional second workflow: knowledge sync
|
||||
## Second live workflow: scheduled quality scan
|
||||
|
||||
RAGcore is not connected in this environment, so the originally sketched "knowledge sync"
|
||||
workflow below remains deferred (see "Deferred: knowledge sync"). The second implemented
|
||||
workflow does not depend on RAGcore or MCP Hub, so it is not blocked by them.
|
||||
|
||||
Input: hourly schedule trigger, or a manual trigger for on-demand testing.
|
||||
|
||||
Steps:
|
||||
|
||||
1. call the narrow, service-token-protected `POST
|
||||
/api/v1/integrations/n8n/scheduled-scan` endpoint;
|
||||
2. the endpoint runs the same deterministic `run_scan()` domain function the manual
|
||||
"Run quality scan" UI action uses, and records a `data_quality_scan_run` audit event
|
||||
with `actor_type=service`;
|
||||
3. return counts of newly created issues per rule type.
|
||||
|
||||
`run_scan()` only ever creates an issue for a condition that does not already have one
|
||||
open, so a duplicate or overlapping trigger (a manual test run firing close to the
|
||||
scheduled one, or a retried HTTP call) does no duplicate domain work.
|
||||
|
||||
The starter export is `n8n/mobilityops-scheduled-quality-scan.json`, imported and
|
||||
published the same way as the return-processing workflow (see
|
||||
`deploy/unraid/setup-scheduled-scan.sh` and `docs/17-runbook.md`). It ships with
|
||||
`"active": false` so it cannot fire against any environment until deliberately
|
||||
published with a real service token.
|
||||
|
||||
## Deferred: knowledge sync
|
||||
|
||||
Input: manual trigger or manifest-changed event.
|
||||
|
||||
@@ -28,7 +55,8 @@ Steps:
|
||||
2. call RAGcore ingestion/sync API;
|
||||
3. record per-document results through MobilityOps integration status API.
|
||||
|
||||
This workflow is useful but must not delay the core demo if RAGcore's final API is not ready.
|
||||
Deferred until RAGcore's live ingestion API is available in this environment; must not
|
||||
delay or block the core demo.
|
||||
|
||||
## Outbox dispatcher
|
||||
|
||||
|
||||
@@ -62,6 +62,35 @@ curl -b cookies.txt http://localhost:8128/api/v1/workflows | grep succeeded
|
||||
A failed/offline n8n does not roll back the return — the outbox event simply stays
|
||||
`pending`/`failed` and is safely retryable from the Automation page.
|
||||
|
||||
### Second workflow: scheduled quality scan
|
||||
|
||||
Import and publish the same way:
|
||||
|
||||
```bash
|
||||
make n8n-setup-scan
|
||||
```
|
||||
|
||||
which runs:
|
||||
|
||||
```bash
|
||||
docker compose exec n8n n8n import:workflow --input=//imports/mobilityops-scheduled-quality-scan.json
|
||||
docker compose exec n8n n8n publish:workflow --id=mobilityops-scheduled-quality-scan
|
||||
docker compose restart n8n
|
||||
```
|
||||
|
||||
Verify:
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8128/api/v1/integrations/n8n/scheduled-scan \
|
||||
-H "X-Service-Token: <MOBILITYOPS_CALLBACK_TOKEN from .env>"
|
||||
# {"created": {...}}
|
||||
```
|
||||
|
||||
Trigger a live run from n8n's own UI ("Manual test trigger" node → Execute Workflow) to
|
||||
confirm the round trip without waiting for the hourly schedule. It does not depend on
|
||||
RAGcore or MCP Hub and ships `"active": false`, so it never fires anywhere until
|
||||
deliberately published with a real service token.
|
||||
|
||||
### Existing shared n8n on the Unraid review server
|
||||
|
||||
The Unraid deployment uses the existing n8n at `http://192.168.10.150:5678`; it does not
|
||||
@@ -85,6 +114,14 @@ inside n8n's protected application data. The callback travels through the Mobili
|
||||
proxy, so the shared n8n container does not need direct database access or membership of
|
||||
the MobilityOps Docker network.
|
||||
|
||||
Publish the scheduled quality-scan workflow the same way:
|
||||
|
||||
```bash
|
||||
./deploy/unraid/setup-scheduled-scan.sh \
|
||||
n8n \
|
||||
http://192.168.10.150:1236/api/v1/integrations/n8n/scheduled-scan
|
||||
```
|
||||
|
||||
## Required operational checks
|
||||
|
||||
- API and web health (`GET /health`, web root `200`);
|
||||
|
||||
Reference in New Issue
Block a user