mirror of
https://github.com/n8n-io/n8n.git
synced 2026-10-22 12:31:57 +02:00
a960366b7c
Adds the cheap bottom rung of preference discovery. `workflows(action="list")` filters on the workflow name only — its own description says so — so learning what a project reaches for meant fetching every workflow and reading its nodes. On ten workflows that is ~6,500 tokens; the same answer from the dependency index is ~85. The index was already there. `WorkflowIndexService` records a `nodeType` row per node per workflow and keeps it current from the same workflow events the activity relay listens to — one records that something changed, the other what it now contains. Nothing exposed it to the agent. Two reads, both project-scoped from the start rather than retrofitted: countNodeTypesForProjects returns the histogram with the scope total, and findWorkflowsByNodeType names the workflows using one, most recently updated first so the freshest example is the one worth reading. Draft rows only — what someone is building says more about preference than what happens to be published — and archived workflows excluded, since those are what the project used to do. Surfaced as `workflows(action="node-usage")`. The description states what it cannot do rather than leaving the agent to over-trust it: node types only, and parameter-level house style still needs a get. The response carries a note that a type absent from the list is used by no workflow in scope, so an absence reads as evidence rather than as a gap in the answer. The activity block gains one line pointing at it, because the feed answers what happened and not what the user tends to build. A sentence, not an injected digest — discovery stays on demand. The repository returns finished rows rather than ids. The first cut had the adapter resolving names with In(...), which trips misplaced-n8n-typeorm-import; pushing the join down fixed the boundary and removed two round-trips, since the query already joins workflow_entity. Verified: two integration tests assert a query cannot reach a project it was not given. The ordering test was checked by inverting the ORDER BY and confirming it fails. Its first version backdated a row with raw `UPDATE ... $1`, which SQLite rejects outright — TypeORM was rewriting it, so the assertion was riding on a driver detail; replaced with a query builder update that is driver-agnostic and bypasses the @BeforeUpdate hook. |
||
|---|---|---|
| .. | ||
| integration | ||
| migration | ||
| shared | ||
| unit | ||
| extend-expect.ts | ||
| global-setup.ts | ||
| setup-mocks.ts | ||
| setup-test-folder.ts | ||
| setup-testcontainers.ts | ||