Turbot Guardrails CLI v1.35.0 - Control run waits for the new run and GraphQL partial matches

Nov 06, 2026•GuardrailsCLI

Breaking changes

  • turbot control run --wait: waits for the new run to finish instead of returning the control's previous state as soon as the run is queued. The exit code and --logs now reflect the new run, and a run longer than --timeout (default 60s) now fails with a timeout.

What's new?

  • turbot graphql: a subcommand with no built-in default output (hub-search, hub-mods, hub-control-types, ...) returns the scalar fields of each item, read from the GraphQL schema, instead of failing with no default graphql output is defined. A defaultGraphqlOutput entry in the config file still wins.
  • turbot graphql --expected: matches when the result has every field the expected value names, with the same value, so a query can select more fields than it waits on. It used to need the whole result to be equal. Arrays must still have the same length and order, each element matching the same way, so items: [] still waits for no items.

Bug fixes

  • turbot configure list, turbot graphql <query> and turbot graphql schema <action>: the help had no Usage: line of its own, so it began like the root help; each now starts with Usage: turbot ..., and a test checks every command's help.
  • turbot control health: showed Healthy: 100% beside Status: UNHEALTHY because the share was rounded to the nearest whole number; it now shows at most 99% while any control is in alarm, error, invalid or tbd, in the text and in summary.healthy of --format=json. Other shares round as before.
  • turbot graphql --expected: a --timeout that was not a multiple of 5 polled for ever, --timeout 0 ran no query, and the time queries took stretched the timeout. The timeout is now a deadline in seconds and the query always runs at least once. A --timeout that is not a number of seconds, 0 or more, is an error.
  • turbot graphql --help: described --output as a file to write results to; it sets the fields a subcommand returns, and the help now says so. The --expected examples wrapped the value in data, which never matches, and the help said a timeout exits 1; it exits 128.