[Validation only - do not merge] API auth uptake checkpoint

[Prangshuman Das (t-prda)]

Validation — runtime BLOCKED

Published and locally validated; fresh AL runtime validation is blocked by GitHub-hosted runner acquisition. Pester117/117 passed, zero failed/skipped, separately at the exact Expense/general/full heads. The existing JSON loader verifies193 temporary method-specific selectors at Expense and zero temporary selectors at general/full. All51 Expense API reenables and nine non-API exclusions remain unchanged; general/full cumulative source trees exactly match the pre-stage-fix checkpoint.

Current exact-head run: https://github.com/microsoft/BCApps/actions/runs/37363759044 (head c4953dceffe02a017adad34973e1955017bf5d20). The bounded2026-10-05T19:57:56Z–19:57:59Z snapshot across the four checkpoint runs found50 cancelled jobs with the same annotation: The job was not acquired by Runner of type hosted even after multiple attempts. Those50 jobs had no assigned runner and executed no steps. No AL unit/integration test jobs had started in that snapshot. Other compilation jobs were active: this is partial hosted-runner availability, not a claimed global outage or a terminal all-green result.

Required next proof: fresh AL execution of all51 Expense API methods and actual suppression of all193 temporary general-stage selectors when runners become available. Historical head88881be evidence—51 methods across13 countries (663 results), all63 touched API methods (819 results), and Activity coverage117/198—is retained separately and does not substitute for this head's runtime validation. General's earlier SQL-pool lifecycle NRE remains a separate unresolved limit; no fixture/classifier/warning workaround or AL retry was added.

Existing runs remain untouched. Do not retry active runs. Parent monitoring schedule46 may stop at this explicit infrastructure blocker; resume bounded review after terminal outcomes/capacity availability, checking exact heads and all new annotations before any separately authorized retry. No Actions cancellation, source/branch update, PR closure, merge, queue or native-stack change is part of this metadata checkpoint.

Expense-first sequencing using existing exclusions

The same 193 method-specific temporary exclusions (135 APIV1 +58 APIV2 across12 codeunits) now live in the existing src/DisabledTests/_Exclude_APIV1__Tests/_Exclude_APIV1__Tests.DisabledTest.json and src/DisabledTests/_Exclude_APIV2__Tests/_Exclude_APIV2__Tests.DisabledTest.json. No separate sequencing files remain. Original entries retain their order/style/content; no new duplicate or wildcard/codeunit-wide exclusion is introduced. Unrelated pre-existing APIV2 duplicates are preserved rather than mixed with this change.

#11860 removes the temporary additions from these same existing manifests alongside its already-reviewed authentication uptake. All193 temporary stage entries are removed in #11860, but it makes 192/193 target methods eligible: the independent 139739::TestDeleteInUse exclusion remains until the VAT fixture fix #11224 removes it. From #11224 onward all193 are eligible; eligibility is not runtime success. All general/downstream cumulative trees are exactly byte-identical to the preceding checkpoint; the full checkpoint has none of these193 methods excluded. No app-name allowlist, selection setting, runner/authentication/test/production change or Logiq exclusion is added.

Why these methods started executing: they already required Disabled isolation and were IntegrationTest codeunits. Ordinary typed selection in TestSuiteMgt332–352 selects None|Codeunit; the old extra Disabled pass in RunTestsInBcContainer was UnitTest-only. The clean-execution switch newly reaches Disabled IntegrationTest codeunits and still honors the existing JSON exclusions. These193 methods were not listed in those exclusions. This is a pre-existing selection gap, not a newly introduced product auth bug or proof they never ran in any historical configuration. A complete67-codeunit audit preserves existing UnitTest/Legacy behavior and the ten independently handled Logiq integration tests.

**Expense scope is unchanged:**51 API reenables, nine non-API exclusions, baseline six cases and all consolidated regressions. The two legacy Spend Requests methods remain conditional on not CLEAN30. Focused #12325 review:21 files, including the two existing exclusion manifests. General #11860 review:159 files.

The official NAV Disable-NAVALTest helper was inspected: it has no destination/app-file parameter, writes NAV's App/DisabledTests using per-codeunit filenames and sorts entries. It cannot safely preserve these BCApps files. A bounded JSON relocation preserved original prefixes/order and checked exact identities, then exercised the unchanged real loader. No new shared helper/framework or NAV selector change was made.

Validation and presentation evidence

Pester117/117 passed independently at the new Expense/general/full heads. Actual existing-loader checks confirm identical effective193-method selection after relocation and preserved51/9 Expense scope. All nine downstream Git tree hashes remain exactly unchanged. Fresh exact-head CI is pending; old-head successes are not substituted for current runtime evidence.

Historical run37330893173 at head88881be reached193 general methods:171 genuine401 failures and22 nominal passes (17 bare-ASSERTERROR cases can accept the wrong error; five local fixtures). Separately, all51 Expense methods passed in13 inspected countries (663 results), and all63 touched API methods yielded819 results; Activity coverage was117/198 at that checkpoint. These are bounded historical results, not a full/current matrix pass. The preceding stage-fix runs hit50 hosted-runner acquisition cancellations; other jobs were active, so this was not a claimed global outage. New pushes schedule fresh CI, not an AL retry. The general SQL-pool NRE and missing warning-reference artifacts remain separate unresolved limitations.

Durable session presentation notes: api-test-enablement-presentation-notes.md, with source-pinned selection proof, fix/coverage inventory, helper limitations and historical-vs-current evidence boundaries. Fresh runtime proof must still establish the51 Expense cases and actual193-case suppression at Expense stage.

AB#646383 (link only). Native stack #12327 remains #12325 → #11860 → #11224 → #11225 → #11226 → #11227 → #11228 → #11229 → #11230 → #11322. Protected merged #10085/#11862/#11891 and validation #11892 are untouched; validation-only #11861/#11455 remain Do Not Merge. No new main integration, native-group/base change, PR merge, queue operation, Actions cancellation or manual retry was made. All prior heads remain ancestors; source publication used backups and an atomic forward-only push with explicit leases.

Exact current head: c4953dceffe02a017adad34973e1955017bf5d20; source tree: 0c79c4094ea8e54fb61edc325ce8166ec9b07b55.

[github-actions]

Issue #11561 is not valid. Please make sure you link an issue that exists, is open and is approved.

[github-actions]

⚠️ Stale Status Check Deleted

The Pull Request Build workflow run for this PR was older than 72 hours and has been deleted.

📋 Why was it deleted?

Status checks that are too old may no longer reflect the current state of the target branch. To ensure this PR is validated against the latest code and passes up-to-date checks, a fresh build is required.

---

🔄 How to trigger a new status check:

1. 📤 Push a new commit to the PR branch, or
2. 🔁 Close and reopen the PR

This will automatically trigger a new Pull Request Build workflow run.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Reject Changes

What this PR does

This checkpoint carries protected API test credentials, clean-tenant execution, shared authentication and date setup, and broad API-suite re-enablement.

The technical changes address the authentication failure, and the available execution evidence supports the approach. However, this is explicitly a validation-only checkpoint that duplicates the intended implementation head and must not be merged through this channel.

Problem-solution fit

Fit: Strong

Shared authentication gives the re-enabled Graph tests access to the generated UserPassword credential. The isolation and fixture changes support running those suites reliably.

Suggestions

S1 (🟠 Moderate): Start the mount timeout after the database copy
The 300-second mount limit also counts dismounting, database copy attempts, and retry delays. Restart the stopwatch immediately before Mount-NAVTenant so a slow copy does not shorten the time allowed for mounting.

Risk assessment and necessity

Risk: The change spans credential lifetime, tenant database replacement, parallel scheduling, and many API test fixtures. Current UserPassword validation is strong, but Windows-authenticated runtime remains unverified, and slow database copies can consume the tenant mount timeout.

Necessity: The authentication and test re-enablement work is necessary. This validation checkpoint is not a valid merge vehicle; the implementation should land through its intended integration path.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11861 round=1 by=alexei-dobriansky at=2026-10-01T22:05:15.125Z lastSha=875726d09d211ec374ca4dbd3a600a1403340ce4 reviewKey=b0a19de2b5c05c61f1a87f7a95ebbf964c5fed2956c2dd9c5b68a3443adb8d39 suggestions=S1@3ae1ce99

[github-actions]

Issue #11224 is not valid. Please make sure you link an issue that exists, is open and is approved.