Requence Lookup

Requence Lookup lets a task ask Requence about Requence. You give it a search — the same search you would type into a list view — and it returns the matching rows, or just how many there are.

The canonical use is a watchdog: an automation that counts failed tasks every few minutes and notifies someone when the number crosses a threshold.

Versions

The service has one version per resource, plus one for counting. Pick the version on the service node; the version is the resource, so there is nothing else to select.

Version	Returns
tasks	Matching tasks — runs, past and present
task-templates	Matching task templates
schemas	Matching schemas
services	Matching services
automations	Matching automations
count	Just the number of matches, for any of the above

There is a version per resource so that the output is properly typed. A tasks node hands downstream nodes real rows — status is the set of task statuses, not “some string” — so logic node scripts get autocompletion and a typo is a red squiggle while you edit instead of a failure at run time. In a script the type is named after the node’s version, e.g. RequenceLookupTasksOutput.

Inputs

Every input is optional except resource on the count version, and every one of them is a node input — so an upstream node can compute the search string, the scope, or the page size.

Input	Meaning
search	The query, in the same syntax as that resource’s list view. Omit it to match everything in scope — an empty string is rejected rather than treated as “everything”, because that is almost always an upstream expression that collapsed.
scope	Where to look. Defaults to the scope of the task doing the lookup.
inherit	Include inherited definitions, like the list view’s inherit toggle. The tasks and automations versions do not offer it at all, because those queries have no such notion; count offers it generically and rejects it for those two resources.
sortField / sortDirection	How to order the rows. The fields are a fixed list per resource; automations takes neither, because it is always ordered by creation.
limit	Rows per call, 1–100. Defaults to 25.
after	A cursor — see Paging.
resource	count only. Which resource to count.

Outputs

The per-resource versions output:

Field	Meaning
items	The matching rows — a compact set of fields per resource, always including id and createdAt
total	How many rows match in total, not just on this page
nextCursor	Present only when there is another page

The count version outputs a single count.

Because total is always there, a tasks node with limit: 1 already answers “how many are there?” — the count version exists for when you want only the number and no row data at all.

Paging

Lookup is deliberately not a pagination API — it caps a single call at 100 rows because the results travel to your service over the message bus. Walking a larger result set is supported, but it has to be visible in the graph:

1. Call the node without after.
2. If the output has a nextCursor, feed it back into the node’s after input and call again.
3. Stop when nextCursor is absent.

Two rules the cursor enforces, so that a walk can never silently return the wrong set:

• A cursor belongs to the query that produced it. Changing the resource or the sort direction mid-walk is an error, not a surprise.
• For resources that take a sort, paging requires sorting by CREATED_AT — the cursor walks creation order and cannot seek through another ordering.

If you find yourself walking thousands of rows, a tighter search is almost always the better answer.

What it can see

A lookup runs as the person behind the task. For a task someone started, that is them; for an automation, it is the person who enabled it. The results are exactly the rows that person would see in the UI — nothing more, and nothing hidden either.

That has consequences worth knowing before you rely on it:

• Permissions are checked when the query runs, not when the template was written. If that person loses access to a scope, the node fails then and there rather than quietly returning stale-authority data. In an automation, that failure goes down the failsafe path.
• You can query a scope the task’s scope cannot structurally reach, as long as the person can. A lookup from a User Space task into a project they are a member of works.
• Tasks started by a webhook or an access token have no person behind them, so Lookup refuses them with a clear message.

Note

Lookup always reads live data, even when the task itself was started from a branch. A branch changes the definitions a task runs, not the data a lookup sees.

When something is wrong

Lookup fails loudly and specifically instead of returning something plausible. An invalid search reports the tokenizer’s error and the character position; an unsupported sort field lists the ones that exist; a cursor from a different query says so. The message aborts the node, so you see it on the node in the task view — and in an automation it flows into the failsafe path like any other node error.