pub struct CheckGroupedOutput {Show 15 fields
pub schema_version: SchemaVersion,
pub version: ToolVersion,
pub elapsed_ms: ElapsedMs,
pub grouped_by: GroupByMode,
pub total_issues: usize,
pub groups: Vec<CheckGroupedEntry>,
pub unused_load_data_keys_global_abstain: bool,
pub baseline_staleness: Option<BaselineStaleness>,
pub finding_id_query: Option<FindingIdQuery>,
pub gate_outcomes: Option<GateOutcomes>,
pub request_outcomes: Option<RequestOutcomes>,
pub package_baselines: Vec<PackageBaselineStatus>,
pub meta: Option<Meta>,
pub workspace_diagnostics: Vec<WorkspaceDiagnostic>,
pub next_steps: Vec<NextStep>,
}Expand description
Envelope emitted by fallow dead-code --group-by ... --format json.
Issues are partitioned into resolver buckets (CODEOWNERS team, directory
prefix, workspace package, or GitLab CODEOWNERS section) instead of flat
arrays. Each bucket carries the same issue-array shape as the ungrouped
CheckOutput body, plus per-group key / owners / total_issues.
Fields§
§schema_version: SchemaVersionDead-code output schema version; currently CHECK_SCHEMA_VERSION.
version: ToolVersionFallow CLI version that produced this output.
elapsed_ms: ElapsedMsWall-clock analysis duration in milliseconds.
grouped_by: GroupByModeResolver the issues were grouped by.
total_issues: usizeTotal findings across all groups.
groups: Vec<CheckGroupedEntry>One bucket per resolver key.
unused_load_data_keys_global_abstain: booltrue when the unused-load-data-key detector abstained for the whole
project. The abstain has no file, so it is on the root and not in a
group. An empty unused_load_data_keys with this flag set does not
mean the project is clean: the rule could not run safely. Serialized
only when true, like the flat CheckOutput field.
baseline_staleness: Option<BaselineStaleness>This run’s view of the loaded baseline, present only in baseline runs.
Carries the staleness counts, the advisory verdict and gate_trips, the
same boolean --fail-on-stale-baseline exits on, so a CI integration
reads one field instead of restating the rule. Read change_scoped
before dividing matched_entries by baseline_entries: a narrowed run
can report matched_entries: 0 on a healthy baseline.
finding_id_query: Option<FindingIdQuery>The answer to --finding-id, present only when the run received one
or more --finding-id values. The report then holds only the
requested findings. Read missing as resolved only when conclusive
is true; a scope, a baseline or a filter can hide a finding that still
exists. See crate::FindingIdQuery.
gate_outcomes: Option<GateOutcomes>The verdict of every gate this run evaluated, keyed by name. The CLI
always emits it, with the command’s default exit rule in it also when
no flag armed a gate, so a CI integration reads the verdict instead of
guessing from a process status it usually cannot see. A gate fails the
build when status is fail AND enforced is true. The typed
programmatic API runs no CLI gate and leaves it absent. See
crate::GateOutcomes.
request_outcomes: Option<RequestOutcomes>Every narrowing or shaping request this run RECEIVED, keyed by name,
absent when it was asked for nothing. An entry whose status is not
applied means the run could not do what it was asked and reported
something WIDER instead, so what follows is a valid report of a scope
nobody requested. Honoured requests are published too, with
status: "applied", so an absent object means “nothing was asked for”,
never “nothing failed”. See crate::RequestOutcomes.
package_baselines: Vec<PackageBaselineStatus>Applied package Git refs, omitted outside package-baseline runs.
meta: Option<Meta>_meta block with docs and rule definitions, when --explain was
passed.
workspace_diagnostics: Vec<WorkspaceDiagnostic>Diagnostics collected for the full analysis before issue grouping.
See CheckOutput::workspace_diagnostics for the contract.
next_steps: Vec<NextStep>Read-only follow-up commands computed from the full (ungrouped) findings.
See CheckOutput::next_steps for the contract.