fix(windows_esp): resolve app validation pagination limit by querying apps individually

[intuneascode]

Summary

Fixes validation error in the Windows Enrollment Status Page resource where app ID validation would fail for applications that weren't in the first 250 results from the Microsoft Graph API. The validation logic now queries apps individually by ID instead of fetching a paginated list, eliminating the pagination limit issue.

Issue Reference

Resolves validation error: supplied app ID '01e267f2-eb89-41b0-a771-09569d65cdda' does not match any valid Windows app types

Motivation and Context

• Problem: The original validation logic fetched all Windows apps with a limit of 250 results (top := int32(250)), causing validation to fail for any app IDs not in that initial batch
• Solution: Changed to query individual apps directly by ID using ByMobileAppId(appIdValue).Get(ctx, nil)
• Benefits:
  • No pagination limits
  • More efficient (only queries the specific apps being validated)
  • Uses SDK type assertions for better type safety
  • Better error messages with specific app details

Dependencies

No new dependencies required. Changes use existing Microsoft Graph Beta SDK patterns.

Type of Change

Please mark the relevant option with an x:

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update (Wiki/README/Code comments)
• ♻️ Refactor (code improvement without functional changes)
• 🎨 Style update (formatting, renaming)
• 🔧 Configuration change
• 📦 Dependency update

Testing

• I have added unit tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Existing unit tests already cover this scenario with mock app IDs

Changes Made

validate.go

• Before: Fetched all Windows apps with OData filter (limited to 250 results) and validated against that list
• After: Validates each app ID individually by querying the Microsoft Graph API directly
• Removed unused deviceappmanagement import
• Added graphmodels import for SDK type assertions
• Changed from string comparison to SDK type switch for validation (*graphmodels.Win32LobApp, *graphmodels.WinGetApp, etc.)

mocks/responders.go

• Before: Mocked list endpoint returning all apps in a collection
• After: Mocks individual app lookups by ID using regex pattern =~^https://graph\.microsoft\.com/beta/deviceAppManagement/mobileApps/[0-9a-fA-F-]+$
• Simple map-based mock data for 5 test app IDs
• Returns minimal required fields (@odata.type and id)
• Error scenario returns 404 for all app IDs

Quality Checklist

• I have reviewed my own code before requesting review
• I have verified there are no other open Pull Requests for the same update/change
• My code follows the established style guidelines of this project
• I have used Microsoft Graph SDK types properly with type assertions
• My changes generate no new warnings
• I have performed a self-review of my own code
• My code is properly formatted according to project standards
• Mock infrastructure follows project patterns (simple in-memory data, no extra JSON files)
• Validation is already called in constructResource() - no additional integration needed

Screenshots/Recordings (if appropriate)

[Add screenshots or recordings that demonstrate the changes]

Additional Notes

Technical Details

Validation Flow:

1. Validates UUID format first (fast, no API calls)
2. For each app ID, makes a direct GET request to /deviceAppManagement/mobileApps/{appId}
3. Uses SDK type assertions to check if the returned app is a valid Windows app type
4. Provides clear error messages if an app doesn't exist or has an invalid type

Supported Windows App Types:

• WindowsAppX
• WindowsMobileMSI
• WindowsUniversalAppX
• OfficeSuiteApp
• WindowsMicrosoftEdgeApp
• WinGetApp
• Win32LobApp
• Win32CatalogApp

Mock Test App IDs:

• 12345678-1234-1234-1234-123456789012 (Win32LobApp)
• 87654321-4321-4321-4321-210987654321 (WinGetApp)
• e4938228-aab3-493b-a9d5-8250aa8e9d55 (Win32LobApp)
• e83d36e1-3ff2-4567-90d9-940919184ad5 (Win32LobApp)
• cd4486df-05cc-42bd-8c34-67ac20e10166 (Win32LobApp)

Files Changed

• internal/services/resources/device_management/graph_beta/windows_enrollment_status_page/validate.go
• internal/services/resources/device_management/graph_beta/windows_enrollment_status_page/mocks/responders.go

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity.
It will be closed in 2 days if no further activity occurs.

[github-actions]

This pull request has been automatically closed due to inactivity.
If you'd like to continue this work, please reopen it or create a new pull request.

[intuneascode]

@ShocOne Any concerns with this PR?

[ShocOne]

why not change the top := int32(250) to say 1000 ? less api calls that way. unless you have an exceptionally large package count, that should suffice ?

[intuneascode]

why not change the top := int32(250) to say 1000 ? less api calls that way. unless you have an exceptionally large package count, that should suffice ?

In a client environment there was > 250 packages, which is where I hit this issue.

[ShocOne]

So your pr just needs to change 1 line to 1000 from 250, rather than a refactor :)