GetWorkItemsByModuleRevisionAsync search using baseline at revision call instead of HEAD work items

[ebakkum]

Fix potentially missing work items when getting items by module revision due to work items being moved or deleted after the specific revision. Updated to query at baseline revision for work items instead of using call that queries work items at the HEAD revision.

[ebakkum]

This currently has an issue with branched documents across different projects due to SearchWorkitemInBaselineAsync having AND project.id:{_config.ProjectId}. It will thus undesirably filter out any work item from the branched from document location.

I am currently working on a solution to address this and ensure accurate results.

[ebakkum]

Summary

Fixes #5 - GetWorkItemsByModuleRevisionAsync was querying work items at HEAD instead of the requested baseline revision, causing items moved or deleted after the target revision to be silently omitted from results.

Before: 156 items returned
After: 159 items returned (matching Polarion UI at that revision)

Root Cause

Step 3 of the algorithm used SearchWorkitemAsync, which queries the current HEAD snapshot. Work items that existed at the target revision but were subsequently moved or deleted were not present at HEAD and therefore dropped from results — even though they are correctly visible in the Polarion UI when viewing that historical document.

Changes

• SearchWorkitemInBaselineAsync replaces SearchWorkitemAsync in step 3, querying the Polarion baseline snapshot at the specified revision rather than HEAD
• includeAllProjects parameter added to SearchWorkitemInBaselineAsync and SearchWorkitemAsync (default: false, backward compatible) - GetWorkItemsByModuleRevisionAsync passes true to avoid the automatic project.id filter excluding work items that belong to other projects via branched documents
• Recycle bin items are not a concern: the preceding step (step 2) explicitly constrains results to only the IDs active in the historical document, so recycled items are naturally excluded

Notes

• No breaking changes - all existing callers of SearchWorkitemAsync and SearchWorkitemInBaselineAsync retain the current scoped-to-project behavior by default
• api.md updated

[schaveyt]

Changes to functionality look good. Changes to the coding style look no bueno.

Add the following to the .csproj

<!--
        Workaround for IDE0005: removed unused directives, we must enable XML
        documentation and ignore the warning it generates (CS1591)
         -->
        <GenerateDocumentationFile>true</GenerateDocumentationFile>
        <NoWarn>IL2026;IL2104;CS1591</NoWarn>
        <AnalysisLevel>10.0</AnalysisLevel>
        <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

[ebakkum]

Formatting

Added requested coding style changes to project with a .editorconfig and enforce code style in build. Ran dotnet format .\src\PolarionApiClient.sln to clean up code and whitespaces.

Benchmark Results: GetWorkItemsByModuleRevisionAsync Fix

Ran a benchmark comparing develop vs this branch using the GetWorkItemsInModule MCP tool from PolarionMcpServers, which calls GetWorkItemsByModuleRevisionAsync under the hood. Tested across 4 document scenarios (2 documents x 2 projects), all querying historical revisions.

Execution Time

Scenario	develop	This Branch	Speedup
Doc A / Project 1	282.3s	65.8s	4.3x faster
Doc A / Project 2	225.7s	63.4s	3.6x faster
Doc B / Project 1	63.7s	10.3s	6.2x faster
Doc B / Project 2	114.5s	29.3s	3.9x faster
Total	686.2s	168.8s	4.1x faster

Work Item Completeness

Scenario	develop	This Branch	Delta
Doc A / Project 1	ERROR (0)	2,720	Fixed - was throwing exception
Doc A / Project 2	563	2,684	+377%
Doc B / Project 1	158	160	+1% (stable)
Doc B / Project 2	296	1,396	+372%

Key Findings

1. Critical bug fixed: On develop, one scenario fails entirely with a URI resolution error when a document references work items from another project. This branch resolves it completely.

2. Missing work items recovered: develop was only searching within the current project scope, returning a fraction of work items for branched documents with cross-project references. The cross-project baseline search recovers 4-5x more items in affected scenarios.

3. Significant performance improvement: Every scenario is 3.6x to 6.2x faster. The new baseline-at-revision search strategy is both more correct and more efficient.

4. No regressions: Documents without cross-project references show near-identical counts (158 vs 160), confirming backward compatibility.

[FrogmanL]

Reviewed with Eric. Reviewed test results and methodology. No issues found. Approve.

Talked to @schaveyt. No additional review is required.