Applying a Docker-label-derived blueprint against a self-hosted Pangolin control plane partially succeeds, creates some private resources successfully, and then fails with:
Blueprint applied with errors: Error: values() must be called with at least one value
Failed to update database from config: Error: values() must be called with at least one value
This appears to be an internal Pangolin bug rather than a user-input validation error.
What I was trying to do
I have a Docker Compose stack with:
nginx
minio
newt
The goal is to publish host-mode private resources into Pangolin for a machine client named dius-sock-proxy.
Initial validation errors
Before fixing the labels, Pangolin correctly returned validation errors such as:
Invalid input: expected string, received undefined at "private-resources.minio.site"
Invalid input: expected array, received string at "private-resources.minio.machines"
Invalid input: expected string, received number at "private-resources.nginx.tcp-ports"
Those were resolved by:
setting site
using machines[0]
ensuring tcp-ports is rendered as a string/range
So the final blueprint shape appears valid.
Rendered blueprint
This is the rendered blueprint as shown by Pangolin:
customer1-nginx private resource is created successfully
customer1-minio-api private resource is created successfully
But Pangolin still logs:
2026-04-02T14:10:05+00:00 [error]: Blueprint applied with errors: Error: values() must be called with at least one value
2026-04-02T14:10:05+00:00 [error]: Failed to update database from config: Error: values() must be called with at least one value
This leaves the blueprint apply in an error state even though the rendered blueprint is valid and the resources are being created.
Environment
OS Type & Version: Docker
Pangolin Version: 1.16.2
Gerbil Version: latest as of date
Traefik Version: 3.6.12.
Newt Version: v1.10.4
Olm Version: (if applicable)
To Reproduce
Minimal reproduction pattern
Create a site in Pangolin.
Create or reference a machine client named dius-sock-proxy.
Run newt against a Docker Compose stack with host-mode private resources similar to:
Observe that the private resources are created, but Pangolin still emits:
values() must be called with at least one value
Extra note
I also saw a related unstable path when trying to model MinIO as multiple or explicit port resources. Some combinations produced different failures, but the key issue here is that even a valid rendered blueprint with successfully created resources can still end in this backend exception.
Expected Behavior
Expected behavior
If the blueprint is valid and resources are created successfully, Pangolin should:
complete the apply successfully, or
return a targeted validation error tied to a specific field/resource
It should not fail with an internal error like:
values() must be called with at least one value
Why this looks like a Pangolin bug
The earlier schema problems produced clear validation errors, which suggests validation is working.
After fixing those issues, Pangolin accepts the rendered structure and creates resources.
The remaining error is an internal backend exception, not a user-facing validation message.
The failure happens during or after blueprint reconciliation, even though at least part of the blueprint has already been persisted.
Originally created by @MarekTran on GitHub (Apr 2, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2768
### Describe the Bug
## Summary
Applying a Docker-label-derived blueprint against a self-hosted Pangolin control plane partially succeeds, creates some private resources successfully, and then fails with:
```text
Blueprint applied with errors: Error: values() must be called with at least one value
Failed to update database from config: Error: values() must be called with at least one value
```
This appears to be an internal Pangolin bug rather than a user-input validation error.
## What I was trying to do
I have a Docker Compose stack with:
- `nginx`
- `minio`
- `newt`
The goal is to publish host-mode private resources into Pangolin for a machine client named `dius-sock-proxy`.
## Initial validation errors
Before fixing the labels, Pangolin correctly returned validation errors such as:
```text
Invalid input: expected string, received undefined at "private-resources.minio.site"
Invalid input: expected array, received string at "private-resources.minio.machines"
Invalid input: expected string, received number at "private-resources.nginx.tcp-ports"
```
Those were resolved by:
- setting `site`
- using `machines[0]`
- ensuring `tcp-ports` is rendered as a string/range
So the final blueprint shape appears valid.
## Rendered blueprint
This is the rendered blueprint as shown by Pangolin:
```yaml
proxy-resources: {}
client-resources: {}
public-resources: {}
private-resources:
nginx:
alias: customer1-nginx.internal
destination: nginx
disable-icmp: false
machines:
- dius-sock-proxy
mode: host
name: customer1-nginx
site: brilliant-scutigera-coleoptrata
tcp-ports: 80-80
minio-api:
alias: minio.customer1.internal
destination: minio
disable-icmp: false
machines:
- dius-sock-proxy
mode: host
name: customer1-minio-api
site: brilliant-scutigera-coleoptrata
tcp-ports: "*"
```
## Observed behavior
Pangolin partially applies the blueprint:
- `customer1-nginx` private resource is created successfully
- `customer1-minio-api` private resource is created successfully
But Pangolin still logs:
```text
2026-04-02T14:10:05+00:00 [error]: Blueprint applied with errors: Error: values() must be called with at least one value
2026-04-02T14:10:05+00:00 [error]: Failed to update database from config: Error: values() must be called with at least one value
```
This leaves the blueprint apply in an error state even though the rendered blueprint is valid and the resources are being created.
### Environment
- OS Type & Version: Docker
- Pangolin Version: 1.16.2
- Gerbil Version: latest as of date
- Traefik Version: 3.6.12.
- Newt Version: v1.10.4
- Olm Version: (if applicable)
### To Reproduce
## Minimal reproduction pattern
1. Create a site in Pangolin.
2. Create or reference a machine client named `dius-sock-proxy`.
3. Run `newt` against a Docker Compose stack with host-mode private resources similar to:
```yaml
services:
nginx:
image: nginx:alpine
labels:
pangolin.private-resources.nginx.name: customer1-nginx
pangolin.private-resources.nginx.alias: customer1-nginx.internal
pangolin.private-resources.nginx.mode: host
pangolin.private-resources.nginx.site: brilliant-scutigera-coleoptrata
pangolin.private-resources.nginx.destination: nginx
pangolin.private-resources.nginx.tcp-ports: 80-80
pangolin.private-resources.nginx.disable-icmp: "false"
pangolin.private-resources.nginx.machines[0]: dius-sock-proxy
minio:
image: minio/minio:latest
command: server /data --console-address ":9001"
labels:
pangolin.private-resources.minio-api.name: customer1-minio-api
pangolin.private-resources.minio-api.alias: minio.customer1.internal
pangolin.private-resources.minio-api.mode: host
pangolin.private-resources.minio-api.site: brilliant-scutigera-coleoptrata
pangolin.private-resources.minio-api.destination: minio
pangolin.private-resources.minio-api.tcp-ports: "*"
pangolin.private-resources.minio-api.disable-icmp: "false"
pangolin.private-resources.minio-api.machines[0]: dius-sock-proxy
```
4. Observe that the private resources are created, but Pangolin still emits:
```text
values() must be called with at least one value
```
## Extra note
I also saw a related unstable path when trying to model MinIO as multiple or explicit port resources. Some combinations produced different failures, but the key issue here is that even a valid rendered blueprint with successfully created resources can still end in this backend exception.
### Expected Behavior
## Expected behavior
If the blueprint is valid and resources are created successfully, Pangolin should:
- complete the apply successfully, or
- return a targeted validation error tied to a specific field/resource
It should not fail with an internal error like:
```text
values() must be called with at least one value
```
## Why this looks like a Pangolin bug
- The earlier schema problems produced clear validation errors, which suggests validation is working.
- After fixing those issues, Pangolin accepts the rendered structure and creates resources.
- The remaining error is an internal backend exception, not a user-facing validation message.
- The failure happens during or after blueprint reconciliation, even though at least part of the blueprint has already been persisted.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @MarekTran on GitHub (Apr 2, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2768
Describe the Bug
Summary
Applying a Docker-label-derived blueprint against a self-hosted Pangolin control plane partially succeeds, creates some private resources successfully, and then fails with:
This appears to be an internal Pangolin bug rather than a user-input validation error.
What I was trying to do
I have a Docker Compose stack with:
nginxminionewtThe goal is to publish host-mode private resources into Pangolin for a machine client named
dius-sock-proxy.Initial validation errors
Before fixing the labels, Pangolin correctly returned validation errors such as:
Those were resolved by:
sitemachines[0]tcp-portsis rendered as a string/rangeSo the final blueprint shape appears valid.
Rendered blueprint
This is the rendered blueprint as shown by Pangolin:
Observed behavior
Pangolin partially applies the blueprint:
customer1-nginxprivate resource is created successfullycustomer1-minio-apiprivate resource is created successfullyBut Pangolin still logs:
This leaves the blueprint apply in an error state even though the rendered blueprint is valid and the resources are being created.
Environment
To Reproduce
Minimal reproduction pattern
dius-sock-proxy.newtagainst a Docker Compose stack with host-mode private resources similar to:Extra note
I also saw a related unstable path when trying to model MinIO as multiple or explicit port resources. Some combinations produced different failures, but the key issue here is that even a valid rendered blueprint with successfully created resources can still end in this backend exception.
Expected Behavior
Expected behavior
If the blueprint is valid and resources are created successfully, Pangolin should:
It should not fail with an internal error like:
Why this looks like a Pangolin bug