Trace
Constructors
Types
We store information on each resolver execution as a Node on a tree. The structure of the tree corresponds to the structure of the GraphQL response; it does not indicate the order in which resolvers were invoked. Note that nodes representing indexes (and the root node) don't contain all Node fields (eg types and times).
represents a node in the query plan, under which there is a trace tree for that service fetch. In particular, each fetch node represents a call to an implementing service, and calls to implementing services may not be unique. See https://github.com/apollographql/federation/blob/main/query-planner-js/src/QueryPlan.ts for more information and details.
Properties
High precision duration of the trace; may not equal end_time-start_time (eg, if your machine's clock changed during the trace). required
Some servers don't do field-level instrumentation for every request and assign each request a "weight" for each request that they do instrument. When this trace is aggregated into field usage stats, it should count as this value towards the estimated_execution_count rather than just 1. This value should typically be at least 1.
Was this operation forbidden due to lack of safelisting?
Was this response served from a full query response cache? (In that case the node tree will have no resolvers.)
If this is true, the trace is potentially missing some nodes that were present on the query plan. This can happen if the trace span buffer used in the Router fills up and some spans have to be dropped. In these cases the overall trace timing will still be correct, but the trace data could be missing some referenced or executed fields, and some nodes may be missing. If this is true we should display a warning to the user when they view the trace in Explorer.
Was this query specified successfully as a persisted query hash?
Did this query contain both a full query string and a persisted query hash? (This typically means that a previous request was rejected as an unknown persisted query.)
If this Trace was created by a Router/Gateway, this is the query plan, including sub-Traces for subgraphs. Note that the 'root' tree on the top-level Trace won't contain any resolvers (though it could contain errors that occurred in the Router/Gateway itself).
Was this operation registered and a part of the safelist?
A tree containing information about all resolvers run directly by this service, including errors.
Fields below this line are not included in inline traces (the traces sent from subgraphs to the Router/Gateway). In addition to details.raw_query, we include a "signature" of the query, which can be normalized: for example, you may want to discard aliases, drop unused operations and fragments, sort fields, etc. The most important thing here is that the signature match the signature in StatsReports. In StatsReports signatures show up as the key in the per_query map (with the operation name prepended). The signature should be a valid GraphQL query. All traces must have a signature; if this Trace is in a FullTracesReport that signature is in the key of traces_per_query rather than in this field. Engineproxy provides the signature in legacy_signature_needs_resigning instead.
Wallclock time when the trace began. required
Optional: when GraphQL parsing or validation against the GraphQL schema fails, these fields can include reference to the operation being sent for users to dig into the set of operations that are failing validation.