`--execute-params` does not check uniqueness of keys

[mcanouil]

I have:

• searched the issue tracker for similar issues
• installed the latest version of Quarto CLI
• formatted my issue following the Bug Reports guide

Bug description

It appears to be possible to have duplicated keys in the YAML file given to --execute-params. The last key wins.
As for any other YAML, I think Quarto should error out.

Steps to reproduce

A Jupyter example but same is happening using knitr as the engine.

---
engine: jupyter
---

```{python}
#| tags: [parameters]

trans = "log1p"
```

```{python}
trans
```

With YAML file:

trans: "log10"
trans: "log2"

quarto render index.qmd --execute-params test.yml

Actual behavior

Quarto takes the YAML and only the last duplicated keys is used without any warnings/errors.

Expected behavior

An error or at least a warning.

Your environment

No response

Quarto check output

Quarto 99.9.9
[✓] Checking environment information...
      Quarto cache location: /Users/mcanouil/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.6.3: OK
      Dart Sass version 1.87.0: OK
      Deno version 2.3.1: OK
      Typst version 0.13.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 99.9.9
      commit: b5438495f9605043dc96e006d494efee5e850dea
      Path: /Users/mcanouil/Projects/quarto-dev/quarto-cli/package/dist/bin

[✓] Checking tools....................OK
      TinyTeX: v2025.05
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/mcanouil/Library/TinyTeX/bin/universal-darwin
      Version: 2025

[✓] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: /Applications/Brave Browser.app/Contents/MacOS/Brave Browser
      Source: QUARTO_CHROMIUM

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.13.1
      Path: /Users/mcanouil/Projects/quarto-dev/quarto-playground/.venv/bin/python
      Jupyter: 5.8.1
      Kernels: julia-1.11, python3

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.5.0
      Path: /Library/Frameworks/R.framework/Resources
      LibPaths:
        - /Users/mcanouil/Projects/quarto-dev/quarto-playground/renv/library/macos/R-4.5/aarch64-apple-darwin20
        - /Users/mcanouil/Library/Caches/org.R-project.R/R/renv/sandbox/macos/R-4.5/aarch64-apple-darwin20/4cd76b74
      knitr: 1.50
      rmarkdown: 2.29

[✓] Checking Knitr engine render......OK

[cscheid]

Interesting. YAML requires keys to be unique (https://yaml.org/spec/1.2.2/#node-comparison) but I think this is a Python bug. Take the Python library:

$ python
Python 3.10.17 (main, Apr  8 2025, 12:10:59) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import yaml
>>> yaml.safe_load("foo: bar\nfoo: baz")
{'foo': 'baz'}

Take the Deno library:

$ deno
Deno 2.3.1
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
> import { parse } from "jsr:@std/yaml";
undefined
> parse("foo: bar\nfoo: baz")

Uncaught SyntaxError: Cannot store mapping pair: duplicated key at line 2, column 1:
    foo: baz

[cscheid]

Pandoc warns on duplicate keys but allows them:

$ cat test.md
---
title: hello
title: hello2
---

## markdown

---
title: hello3
---
$ pandoc -f markdown -t json -i test.md
[WARNING] YAML warning (test.md line 1 column 1): Duplicate key: .title
{"pandoc-api-version":[1,23,1],"meta":{"title":{"t":"MetaInlines","c":[{"t":"Str","c":"hello3"}]}},"blocks":[{"t":"Header","c":[2,["markdown",[],[]],[{"t":"Str","c":"markdown"}]]}]}

[mcanouil]

But in this case inside Quarto to get nothing at all.
Note that it's note about metadata but parameters. Is Pandoc really involved in parameters which are only used for computations?

[cscheid]

Is Pandoc really involved in parameters which are only used for computations?

That wasn't my point. I'm pointing out the diverging behavior between YAML parsers when it comes to duplicate keys.

[mcanouil]

Is Pandoc really involved in parameters which are only used for computations?

That wasn't my point. I'm pointing out the diverging behavior between YAML parsers when it comes to duplicate keys.

Got it 👍

[cderv]

For the --execute-params file we do use JS Yaml parser

quarto-cli/src/command/render/flags.ts

Lines 517 to 535 in f2bb894

	// resolve parameters (if any)
	export function resolveParams(
	params?: { [key: string]: unknown },
	paramsFile?: string,
	) {
	if (params || paramsFile) {
	params = params || {};
	if (paramsFile) {
	params = mergeConfigs(
	readYaml(paramsFile) as { [key: string]: unknown },
	params,
	);
	}
	return params;
	} else {
	return undefined;
	}
	}

quarto-cli/src/core/yaml.ts

Lines 55 to 59 in f2bb894

	export function readYaml(file: string) {
	if (existsSync(file)) {
	const decoder = new TextDecoder("utf-8");
	const yml = Deno.readFileSync(file);
	const result = parseWithNiceErrors(decoder.decode(yml));

quarto-cli/src/core/yaml.ts

Lines 292 to 298 in f2bb894

	function parseWithNiceErrors(
	content: string,
	// deno-lint-ignore no-explicit-any
	options?: any,
	) {
	try {
	return parse(content, options || { json: true, schema: QuartoJSONSchema });

And this library does the same behavior as the Python library, and only keep the last key

@cscheid this is different from your Deno library test.

Which YAML parsing library are we using exactly ? I see parse() is from js-yaml

quarto-cli/src/core/yaml.ts

Line 40 in f2bb894

export const parse = load;

I was puzzled so I tried to understand and it seems this library as a JSON mode that use, and does not fail on duplicated keys

Here is debug content from we read the YAML param file at

quarto-cli/src/core/yaml.ts

Line 298 in f2bb894

return parse(content, options || { json: true, schema: QuartoJSONSchema });

$ content
'trans: "log10"
trans: "log2"'
$ parse(content)
Uncaught YAMLException$1 YAMLException$1
    at generateError (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:928:10)
    at throwError (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:931:9)
    at storeMappingPair (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:1050:7)
    at readBlockMapping (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:1594:9)
    at composeNode (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:1779:78)
    at readDocument (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:1911:3)
    at loadDocuments (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:1953:5)
    at load$1 (cdn.skypack.dev/-/js-yaml@v4.1.0-dDv6O5b7vFYj0Ro3QdID/dist=es2019,mode=imports/optimized/js-yaml.js:1971:19)
    at eval (repl:1:1)
$ parse(content, { json: true })
{trans: 'log2'}

It seems we are using this option in several places, and so don't detect this type of YAML rules.

Looking at documentation, this is expected
https://www.npmjs.com/package/js-yaml#load-string---options-

json (default: false) - compatibility with JSON.parse behaviour. If true, then duplicate keys in a mapping will override values rather than throwing an error

So if we want to catch that we need to change parser, or do it differently it seems.

@cscheid I see you added upstream label. I don't know if this is for the Python yaml parsing difference that you mention, but it is not used here. To me this is all our doing by using { json: true } option in the library we use for YAML parsing in JS.

[cscheid]

@cderv You're right that this isn't an upstream issue with python's yaml parsing, then.

(But it's still unclear to me that we should consider it a bug.)

[mcanouil]

(But it's still unclear to me that we should consider it a bug.

I agree. It could be a "documentation" issue, in the sense that this behaviour for parameters could be highlighted.

[cderv]

It is just that for anything where we have YAML validation we do stop on duplicated keys

---
title: test
format: html
toc: true
toc: false
---

# content

❯ quarto render index.qmd
ERROR: YAMLException: duplicated mapping key (C:\Users\chris\Documents\DEV_OTHER\00-TESTS\test-quarto\index.qmd, 5:1)
4: toc: true
5: toc: false
  ~~
6: ---

Which means we don't parse the YAML header the same as the execute params (probably not setting json: true ?) So I see that as an enhancement to also do it for --execute-params yaml file.

I know we can't validate the file the same, as we don't know its schema. But as you said,

YAML requires keys to be unique (yaml.org/spec/1.2.2#node-comparison)

It seems to me that users would expect that Quarto errors on bad yaml
So the same when you considered this a Python library bug, this could be seen as a bug for Quarto that we are less strict when reading this parameters yaml file. After all, this is a choice of ours to use { json: true } option and be less strict.

Anyhow, if we don't plan to change that, documenting that --execute-params won't be validated could be the least we could do.