When giving non-string environment variable, all environment variables disappear

[Lopolin-LP]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.

flatpak-builder version

1.4.9

Flatpak version

1.16.6

How to reproduce

1. setup temporary folder
2. create com.example.example.yml with content below
3. run flatpak-builder --force-clean --disable-cache ./build com.example.example.yml
4. test1 will have no environment variables at all, while test2 has them. The error printed to console will be (flatpak-builder:251302): Json-WARNING **: 19:48:27.885: Failed to deserialize "env" property of type "GStrv" for an object of type "BuilderOptions"

id: com.example.example
runtime: org.freedesktop.Platform
runtime-version: '25.08'
sdk: org.freedesktop.Sdk
command: /bin/false
modules:
  - name: test1
    buildsystem: simple
    build-options:
      env:
        VAR1: Test!
        VAR2: 1
        VAR3: null
    build-commands:
      - echo "${VAR1}"
      - echo "${VAR2}"
      - echo "${VAR3}"
  - name: test2
    buildsystem: simple
    build-options:
      env:
        VAR1: Test!
        VAR2: "0"
        VAR3: null
    build-commands:
      - echo "${VAR1}"
      - echo "${VAR2}"
      - echo "${VAR3}"

This is not specific to yml, happens with json too

{
    "id": "com.example.example",
    "runtime": "org.freedesktop.Platform",
    "runtime-version": "25.08",
    "sdk": "org.freedesktop.Sdk",
    "command": "/bin/false",
    "modules": [
        {
            "name": "test1",
            "buildsystem": "simple",
            "build-options": {
                "env": {
                    "VAR1": "Test!",
                    "VAR2": 0
                }
            },
            "build-commands": [
                "echo \"${VAR1}\"",
                "echo \"${VAR2}\""
            ]
        },
        {
            "name": "test2",
            "buildsystem": "simple",
            "build-options": {
                "env": {
                    "VAR1": "Test!",
                    "VAR2": "0"
                }
            },
            "build-commands": [
                "echo \"${VAR1}\"",
                "echo \"${VAR2}\""
            ]
        }
    ]
}

Expected Behavior

in the case of an unexpected non-string given as an environment variable:

• Throw out troublesome environment variable and print warning/error
• Convert troublesome environment variable to string (if possible), otherwise print warning/error
• Cancel build and print error, pointing to the faulty environment variable

Actual Behavior

No environment variables available at all. Rest of the console log:

(flatpak-builder:251302): Json-WARNING **: 19:48:27.885: Failed to deserialize "env" property of type "GStrv" for an object of type "BuilderOptions"
Emptying app dir './build'
Downloading sources
Initializing build dir
Committing stage init to cache
Starting build of com.example.example
========================================================================
Building module test1 in /home/lopolin/Temp/FlatpakEnvFailTest/.flatpak-builder/build/test1-1
========================================================================
Running: echo "${VAR1}"

Running: echo "${VAR2}"

Running: echo "${VAR3}"

Committing stage build-test1 to cache
========================================================================
Building module test2 in /home/lopolin/Temp/FlatpakEnvFailTest/.flatpak-builder/build/test2-1
========================================================================
Running: echo "${VAR1}"
Test!
Running: echo "${VAR2}"
0
Running: echo "${VAR3}"

Committing stage build-test2 to cache
Cleaning up
Committing stage cleanup to cache
Finishing app
Please review the exported files and the metadata
Committing stage finish to cache
Pruning cache

Additional Information

Please update the documentation (such as in flatpak-manifest(5)) to mention that all environment values must be strings or null.

[bbhtt]

PR for the doc is welcome, the other problem is these warnings are not fatal but they should be in general. See #483, #597 for similar issues and also some were made fatal.