Reference

operations.logs queries

Package Trax.Api.GraphQL·Surface GraphQL schema·Source LogQueries.cs

LogQueries, the type behind operations { logs { ... } }.

The operations.logs namespace returns paginated reads of trax.log, the framework's per-execution log table. The dashboard's Logs page is backed by this query. Logs are written by the framework, never by API consumers, so there are no log mutations.

query {
  operations {
    logs {
      logs(skip: 0, take: 50, minimumLevel: WARNING) {
        items { id metadataId eventId level category message exception stackTrace }
        totalCount
        isEstimatedCount
        nextCursor
      }
    }
  }
}

A run's log, oldest first as its page reads it, filtered by text:

query {
  operations {
    logs {
      logs(metadataId: 1234, order: OLDEST, messageContains: "timeout", take: 100) {
        items { id level category message }
        totalCount
        isCountCapped
        nextCursor
      }
    }
  }
}

Returns: PagedResult<LogEntry>.

The filters, the order and the counts go through IOperationsService in Trax.Scheduler, the same LogQuery the dashboard's Logs and run pages read with, so both apply one filter.

The count depends on the filter. Unfiltered, it is the same pg_class.reltuples estimate as the other large-table queries (isEstimatedCount: true), because the log table grows quickly. With messageContains or categoryContains it counts at most 10,000 matches: past that totalCount is 10000 and isCountCapped is true, so a client shows "10,000+" rather than waiting on a count of millions of rows. Under any other filter, or a text filter matching 10,000 or fewer, it is exact.

On Postgres the text filters are served by trigram indexes on lower(message) and lower(category). At 3,000,000 log rows a page with its count takes a few milliseconds for a term that matches nothing, under 70 ms for one that matches often, and under 200 ms for one that matches a single row. A term that matches often but only in old rows takes under 50 ms newest first: a first or cursor page with a text filter reads the 10,000 ids nearest where it starts in order, then finds the rest of its matches through the index, so it does not walk every newer row.

LogEntry fields

See also

• Queries
• PagedResult