500 on GET /api/stacks — orphaned stacks reference deleted workflows after 2.43.0 migration

Before you start please confirm the following.

• Yes, I've searched similar issues on GitHub.
• Yes, I've checked whether this issue is covered in the Portainer documentation.

Problem Description

After migrating from 2.42.0 to 2.45.0, the Stacks page is unusable for every environment. Two stack records left over from environments that no longer exist reference workflow IDs that no longer exist either. Every stack handler resolves the git config before anything else, so these records cannot be read, deleted, or re-associated through any API route.

Expected Behavior

A stack referencing a missing workflow should be skipped, reported individually, or at minimum still be deletable. One inconsistent record should not break the whole list.

Actual Behavior

GET /api/stacks returns 500 for all environments:

{"message":"Unable to load git config for stack","details":"Object not found inside the database (bucket=workflows, key=10)"}

The two records at fault:

Both are git-backed compose stacks (Type 2) created in late 2024, deploying nothing today.

Every route fails with the same error:

• GET /api/stacks/135 → 500
• GET /api/stacks/135/file → 500
• PUT /api/stacks/135/associate?endpointId=<valid>&orphanedRunning=false → 500
• DELETE /api/stacks/135?endpointId=16 → 404 Object not found inside the database (bucket=endpoints, key=16) (the handler resolves the endpoint from the stack record, not from the query parameter)
• DELETE /api/stacks/135?endpointId=<valid>&external=true → 500 This node is not a swarm manager (external mode takes the Swarm path on a standalone environment)

The documented recovery path (Stacks → ⋮ → Show all orphaned stacks → Associate) is unreachable, since the Stacks page is exactly what 500s.

Steps to Reproduce

1. On 2.42.0 or earlier, deploy a git-backed stack to an environment.
2. Delete that environment (the stack record remains, as an orphaned stack).
3. Upgrade to 2.43.0+ so the migration converts git-backed stacks to Source+Workflow records.
4. Delete the workflow that the orphaned stack points to.
5. Open the Stacks page on any environment — the UI always sends IncludeOrphanedStacks: true, and the request 500s.

Portainer logs or screenshots

No response

Portainer version

2.45.0

Portainer Edition

Business Edition (BE/EE) with 5NF / 3NF license

Platform and Version

Docker version: 29.4.3, standalone

OS and Architecture

Platform: linux/arm64

Browser

No response

What command did you use to deploy Portainer?

Additional Information

Workflow IDs 35, 40 and 50 are absent and unreferenced — clean deletions. Only 10 and 11 are referenced by a stack while missing, so this looks like two isolated inconsistencies rather than a systematic migration failure. Stacks and workflows map 1:1 in this instance, with no unreferenced workflow available, so remapping the dangling IDs to a live workflow isn't a safe workaround either.

Possibly related: portainer/portainer#2771 (Cannot delete stack after endpoint is deleted), which predates the Workflows model but describes the same dead end.