Skip HTTP workflow route matching outside base path

[sfmskywalker]

Summary

• Short-circuit HTTP workflow middleware before route matching when the request is outside the configured base path.
• Preserve route matching and base-path stripping for requests inside the base path.
• Add middleware unit coverage for both outside-base-path bypass and inside-base-path route resolution.

Fixes #7709

Tests

• dotnet test test/unit/Elsa.Http.UnitTests/Elsa.Http.UnitTests.csproj

[greptile-apps]

Greptile Summary

This PR changes HTTP workflow middleware to skip route matching outside the configured base path. The main changes are:

• Moves route matching until after the base-path check.
• Keeps base-path stripping for requests that pass the base-path check.
• Adds unit coverage for outside-base-path bypass and inside-base-path route resolution.

Confidence Score: 3/5

The change is targeted but may break route-prefix multitenancy by bypassing tenant-prefixed workflow routes before route matching.

Unit coverage covers the intended base-path behavior, but the middleware path check appears to exclude valid tenant-prefixed workflow requests.

src/modules/Elsa.Http/Middleware/HttpWorkflowsMiddleware.cs

T-Rex Logs

What T-Rex did

• Created a focused xUnit middleware repro targeting /acme/workflows/foo with BasePath /workflows to verify tenant-route matching and confirm that next is not called.
• Attempted to run the focused dotnet test command, but the environment could not execute it because dotnet is not installed, yielding an exit code of 127.
• Documented the blocker: the repository is a .NET solution, but the runtime environment lacks the dotnet executable, preventing test execution of HttpWorkflowsMiddleware.InvokeAsync.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. src/modules/Elsa.Http/Middleware/HttpWorkflowsMiddleware.cs, line 48-51 (link)

   Tenant routes are skipped

   This early check compares the raw request path to BasePath before route matching. In route-prefix multitenancy, workflow routes are registered as /{tenantPrefix}/workflows/... while BasePath remains /workflows, so a valid request such as /acme/workflows/foo does not start with /workflows. This branch then calls next and returns before GetMatchingRoute can match the tenant-prefixed route, so tenant-prefixed HTTP workflows stop starting or resuming.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/modules/Elsa.Http/Middleware/HttpWorkflowsMiddleware.cs
   Line: 48-51
   
   Comment:
   **Tenant routes are skipped**
   
   This early check compares the raw request path to `BasePath` before route matching. In route-prefix multitenancy, workflow routes are registered as `/{tenantPrefix}/workflows/...` while `BasePath` remains `/workflows`, so a valid request such as `/acme/workflows/foo` does not start with `/workflows`. This branch then calls `next` and returns before `GetMatchingRoute` can match the tenant-prefixed route, so tenant-prefixed HTTP workflows stop starting or resuming.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
src/modules/Elsa.Http/Middleware/HttpWorkflowsMiddleware.cs:48-51
**Tenant routes are skipped**

This early check compares the raw request path to `BasePath` before route matching. In route-prefix multitenancy, workflow routes are registered as `/{tenantPrefix}/workflows/...` while `BasePath` remains `/workflows`, so a valid request such as `/acme/workflows/foo` does not start with `/workflows`. This branch then calls `next` and returns before `GetMatchingRoute` can match the tenant-prefixed route, so tenant-prefixed HTTP workflows stop starting or resuming.

_{Reviews (1): Last reviewed commit: "Skip HTTP workflow route matching outsid..." | Re-trigger Greptile}