{
  "id": 3070601,
  "title": "That time YAML silently broke your config because of Norway",
  "url": "https://urgent.news/2026/08/24/that-time-yaml-silently-broke-your-config-because-of-norway",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-24T17:05:31.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/schiff_heimlich/that-time-yaml-silently-broke-your-config-because-of-norway-43dj"
  },
  "original_language": "en",
  "account": "A colleague recently encountered a confusing YAML configuration issue while working on a project. The problem stemmed from a misinterpreted value assigned to the \"country\" field. The developer had intended to set the country code to \"NO\" for Norway, but YAML interprets unquoted strings as booleans. Consequently, \"NO\" was read as \"false\" by YAML parsers. As a result, the application started, loaded the configuration, and continued running without displaying any error messages. It merely performed the incorrect action by setting the country to \"false\" instead of \"NO.\"\n\nThis behavior has been documented for years and has affected various systems, including DoorDash, Kubernetes manifests, CI configurations, Terraform variables, GitHub Actions, and Helm charts. The issue lies in the fact that YAML silently coerces the misinterpreted value, making debugging challenging since there is no error message displayed. Instead, the application exhibits unexpected behavior, such as the country code field being read as a boolean instead of a string.\n\nTo avoid such silent failures, it is recommended to quote strings when assigning values to fields in YAML files. For example, using \"country: \"NO\"\" ensures that the value is treated as a string rather than a boolean. Additionally, adopting the strict YAML subset introduced by the SIG CLI KEP 5295, which quotes strings, braces maps, and brackets lists, can help eliminate ambiguity surrounding whitespace and capitalization issues. Linting tools like yamllint can also assist in catching some of these problems, but they may not always detect semantic boolean confusion without schema awareness.\n\nIn practice, developers should make it a habit to quote any values that could potentially be misinterpreted as booleans or other data types. By simply adding quotes around string values, such as \"country: \"NO\"\" or \"flag: \"false\"\", developers can prevent a class of silent failures that often go unnoticed until they become problematic. This simple discipline can save a significant amount of time and effort in tracking down unexpected behavior in YAML files.",
  "summary": "A colleague pinged me last week with a config issue that had him chasing his tail for an afternoon. Turns out he was setting country: NO in a YAML file, expecting it to mean Norway. YAML thought he meant boolean false. The Problem YAML 1.1 treats these unquoted strings as booleans: yes , no , on , off , true , false Case-insensitive variants work too So if you have: database : country : NO…",
  "key_points": [
    "YAML misinterprets unquoted \"NO\" as boolean false",
    "Application runs without error, uses \"false\" instead of \"NO\"",
    "Quote strings to prevent silent boolean coercion"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}