WorkflowDefinitions List endpoint does not use Labels from Request

[StevenMcCawley-Davies]

Description

The GET /workflow-definitions endpoint does not use Labels from the request object

Steps to Reproduce

To help us identify the issue more quickly, please follow these guidelines:

1. Detailed Steps: Hit the GET /workflow-definitions with any real label string in the "Label" section of the request.

2. Code Snippets:

4. Reproduction Rate: 100% of the time

Expected Behavior

I expect the request to filter results by label

Actual Behavior

The endpoint does not filter results by label

Environment

• Elsa Package Version: Elsa 3.7

[sfmskywalker]

I am picking this up against current main (07f788a). I will trace how the list endpoint applies the requested labels and add a regression that demonstrates the ignored filter before fixing it. The intended scope is to make this endpoint honor its existing label-filter contract while retaining unfiltered requests and composition with other filters. I will post the reproduction result and link the PR here once validated.

[sfmskywalker]

Source diagnosis on current main confirms that the request binds label values but never uses them when constructing the workflow-definition filter. Existing label assignments use label IDs and are tied to individual workflow versions. I am implementing an optional filter provider supplied by the Labels module, resolving matching version IDs before paging and counting. This preserves the module boundary and combines label matching with the existing ID/search/version filters; unknown labels must return an empty result. I will report the executable regression results next.

[sfmskywalker]

The regression is reproduced in executable endpoint-handler tests: without the label mapping, a request expected to match two versions returns all five fixture versions, and unknown labels also return unrelated results. With the fix, all eight focused tests pass, including pagination totals, label/ID intersection, and HTTP 501 without an unfiltered store query when filtering is unsupported. Label matching is by ID with any-match semantics and respects individual versions. A linked Extensions change is also needed for its built-in MongoDB label store; I will keep this issue open until that adapter and Core are both delivered and their package compatibility is validated.

[sfmskywalker]

Core PR #8035 is ready for review. All 31 API tests pass, including eight focused label regressions, and Workflows.Api, Labels, and EFCore build for .NET 8, 9, and 10 with zero errors. API/Labels builds are warning-free; EFCore reports existing Identity XML-documentation warnings. Self-review and independent review found no remaining required changes. Copilot review and CI have been requested. The MongoDB adapter is prepared in an isolated Extensions branch; its final build and integration validation await the exact Core preview package from this change. This issue remains open until both repository changes are delivered.

[sfmskywalker]

CI passed on PR #8035, but automated review identified two changes needed before merge. I confirmed that label filtering must require the existing workflows/definitions/labels:view permission, since the result can reveal label assignments. I am adding that check before any label lookup. I am also replacing the shared provider-applied flag so an unrelated filter provider cannot make an unresolved label filter appear handled. Both paths will have regression coverage; the MongoDB adapter will be validated against the final reviewed Core package.

[sfmskywalker]

The two review findings are fixed and pushed in PR #8035 (0deacc1). Label-filtered requests now enforce the separate permission to view label associations before querying either store, and unresolved label criteria fail with 501 even if another filter provider runs. The regression tests reproduced the incorrect successful responses before the fix; all 11 focused and 34 API tests now pass. API and Labels builds pass on .NET 8, 9, and 10. I have replied to both findings and requested review again. The MongoDB integration already passes four live tests against the earlier published candidate; I will repeat compatibility validation against the updated Core packages before delivering this issue across both repositories.

[sfmskywalker]

The Core portion is merged in PR #8035 as cbdc3f7. Copilot approved the final commit with no new findings, Greptile reported 5/5, both review threads were resolved, and all 21 checks completed successfully or were intentionally skipped. The reviewed packages are published as 3.8.0-preview.5557. I am keeping this issue open while completing the required MongoDB adapter in Elsa Extensions and validating it against those exact packages. Core merge alone does not yet complete the cross-repository fix.

[sfmskywalker]

The companion MongoDB change is ready for review in elsa-workflows/elsa-extensions#178. It adds tenant-scoped any-label lookups using workflow version IDs, a LabelId index, and a coherent Core package update to the published 3.8.0-preview.5557 build. The entire Extensions solution restores successfully; Mongo builds pass on .NET 8/9/10; all four Mongo tests pass, including live tenant isolation and the actual Core filter provider calling MongoDB. The package provenance matches the reviewed Core commit. Self-review and independent review found no required changes. Copilot review and CI are now requested for the companion PR; this issue remains open until it merges.

[sfmskywalker]

The companion PR passed CI and received Copilot approval. CodeQL subsequently posted a concrete test-fixture cleanup finding: the MongoClient must be disposed explicitly after each live test. I am addressing that lifecycle issue, then rerunning the Mongo tests and requesting review/checks for the updated commit before merging. The workflow-label behavior and cross-repository scope are unchanged.

[sfmskywalker]

Delivered across both repositories: Core PR #8035 merged as cbdc3f7, and elsa-workflows/elsa-extensions#178 merged as 2261e3e. The list endpoint now resolves requested label IDs to matching workflow version IDs before filtering, counting and paging. Multiple IDs use any-label matching; unknown IDs return no matches; existing ID filters are intersected. Label-filtered requests enforce the separate label-association read permission, and unsupported label-store configurations return 501. Built-in in-memory, EF Core and MongoDB label stores support the query.

Validation: 11 focused endpoint tests and 34 API tests passed; Core CI passed 3,434 unit/integration tests with 126 skips. MongoDB passed all four live tests against the actual reviewed Core packages (3.8.0-preview.5557), including tenant isolation and provider-to-adapter integration; final Extensions CI passed 165 tests with two skips. Relevant module builds passed on .NET 8/9/10. Both PRs passed current-head Copilot review and all CI checks; Core Greptile reached 5/5. No Greptile run was detected for the Extensions PR after requesting it.

The fix is merged on main. This does not retrofit an existing 3.7 installation; that installation must adopt a build containing these changes. The live Mongo tests cover the persistence/provider boundary, while Core tests cover the endpoint handler; a full cross-repository HTTP host was not part of the validation. Closing as resolved.