[Diagnostic only] Paired SQL reset database-name pilot on PR2

[Prangshuman Das (t-prda)]

Diagnostic only — DO NOT MERGE / DO NOT QUEUE

Related context: AB#646383. This experiment does not resolve that work item.

Separate, ungrouped experiment on exact PR #11860 head
c4953dceffe02a017adad34973e1955017bf5d20. This experiment does not modify the
existing native stack, native group 12327, main, or separate authentication experiment #12441.
Base is features/646383-api-test-uptake only for a clean experimental diff.

One predeclared paired pilot

• Two fresh disposable GitHub-BCAppsPL W1 Integration containers, 120 minutes per arm / 240 runner-minutes maximum, matrix fail-fast disabled.
• Control: reuse tenant2, tenant3, tenant4 SQL names.
• Treatment: identical logical tenant IDs/URLs, fresh run/generation-qualified database names on every reset, including discovery restore.
• Identical PR2 source and compiled app/test artifacts from run 37372848860, exact artifact IDs and SHA256 checks; pinned BCH 6.1.19-preview2811389, NST 30.0.55665.0, application artifact 30.0.55683.0, generic image digest.
• Preserve original discovery, assertions, auth and three-worker batches. Verify and execute the captured 21-codeunit prefix through Expense Users/Capabilities/Activity Log once. Stop after target batch or a failed batch.
• No AL changes, user credential/key changes, extra HTTP warmup, arbitrary waits, force-refresh, pool clearing or retries. Original mount polling remains. Baseline copy/transient retries disabled in both arms.
• Track actual mounted mapping and strict worker ownership before dismount/delete/copy/mount. Preserve source/default/application/template databases until disposable whole-container teardown.
• Export UTC reset labels, read-only SQL identities, NST PID/version, package hashes, worker logs, JUnit and EVTX without adding credential/header diagnostics. Both arms perform the same administrative probes.

CI isolation

This branch intentionally replaces the already-registered CICD.yaml manual entry point with only the bounded pair. It disables normal full-country PR project discovery for this experiment branch only. No automatic dispatch, merge, native-stack enrollment or queue action.

Both arms used the same pinned generic-image digest. Their actual generic banner
is 1.0.2.128; the historic source run logged 1.0.2.128-dev without a digest,
so identical image bits to that historical run are not established. A timeout,
setup drift, missing artifact, early assertion or no reproduction is not a fix.
Even control-only reproduction would be just a name-reuse signal; SQL names do
not directly identify NST pool generations.

Validation

• 100/100 Pester 5 tests passed: existing parallel-harness regression coverage plus 13 diagnostic mapping/ownership/failure/cleanup tests.
• Changed PowerShell parsed; workflow YAML parsed; git diff --check clean.
• src is byte-for-byte unchanged against pinned PR2.
• Built-in read-only code review: no significant findings. No external review engine or host-security changes.

See build/scripts/SqlResetPilot/README.md for the complete protocol and boundaries.

Preparation failure and authorized replacement

Initial run: https://github.com/microsoft/BCApps/actions/runs/37493608127

Both arms failed before container creation or AL tests. The experiment incorrectly
specified Windows PowerShell 5.1 instead of the original W1 job's pwsh 7.
The platform-index HTTP response could not be parsed because the IE engine was
unavailable. This is a preparation/configuration bug, not a network failure or
SQL outcome. Raw logs and both diagnostic artifacts are preserved; the pair
is inconclusive. Preparation consumed 13m16s + 14m23s = 27m39s runner time.

One replacement pair was explicitly authorized:
https://github.com/microsoft/BCApps/actions/runs/37496613531

Corrected head: ae6513a3a3b8902513e69af929331c17272a221d.
Only experiment workflow configuration and directly related documentation changed:
job/default and all three AL-Go composite action shell inputs now use pwsh;
a preflight requires and records PowerShell 7. No PlatformHelper/vendor code,
global UseBasicParsing setting or shell policy was changed.

Validation on PowerShell 7: 100/100 Pester tests passed, YAML shell/budget
checks passed, and the unchanged Get-PlatformVersionUrl successfully resolved
the exact 30.0.55665.0 platform index. AL source remains unchanged.

Replacement cap: 120 minutes per arm / 240 additional runner-minutes;
cumulative worst-case including failed preparation is 267m39s.
No further pair or failed-job rerun is authorized.

Final paired result: both pass; hypothesis remains inconclusive

Verified completed run: https://github.com/microsoft/BCApps/actions/runs/37496613531

Arm	Job	Executed pass / fail / skip	Runner time	Completed UTC
Reused SQL names	112382673163	234 / 0 / 19	70m27s	2026-10-06T17:45:07Z
Fresh SQL names	112382672875	234 / 0 / 19	79m55s	2026-10-06T17:54:14Z

• Both completed all seven original three-worker batches, with the same
  21-codeunit worklist and tenant assignments. JUnit contains 253 case nodes per
  arm: 234 actually executed and passed, 19 skipped. One scheduled codeunit,
  139972, has all 17 methods skipped, exactly as in the original run; do not count
  it as executing assertions. JUnit's suite tests=0 attributes are not reliable
  counts here—the figures above come from actual testcase/skip/failure nodes.
• All 19 Expense target methods passed in both arms: Users 2, Capabilities 8,
  Activity Log 9. All method names and skip masks match the original W1 JUnit
  artifact 11411405840 from run 37372848860 / job 112207627851.
• All 248 package names and SHA256 hashes match across arms (117 application
  and 131 test packages), with the exact pinned PR2 archive IDs/head. Both actually
  used NST 30.0.55665.0, BCH 6.1.19-preview2811389, the same pinned image digest,
  W1 application artifact 30.0.55683.0, PowerShell 7.6.6 and host OS
  10.0.26100.0. Historical image identity remains the limitation above.
• Each arm completed 22 resets: discovery plus seven batches. Control reused
  tenant2/3/4; treatment mounted 22 distinct
  tenantN_r37496613531_gGENERATION database names while preserving the same
  logical tenant IDs. Every observed mounted name and subsequent previous-name
  mapping matches the recorded ownership chain.
• The SQL database_id values remained 8/9/10 per logical tenant in both
  arms, and the observed service-broker GUID stayed the same. Fresh names did not
  produce fresh IDs/GUIDs. Internal NST database/pool generation remains unobserved.
• No AcquireSqlConnectionFromPool, NullReferenceException or
  GetRelativeHelpUrl signature appeared in either complete uploaded EVTX:
  10,848 control events, 11,497 treatment events, including image history.
  This is bounded captured-log evidence, not a guarantee beyond these executions.
• Both ownership-checked final records report containerRemaining=false;
  ordinary teardown is also present in both job logs. Raw JUnit, EVTX, worker
  output, package manifests and reset timelines are preserved in artifacts
  11432130703 (control) and 11432516529 (treatment).

The replacement used 150m22s total runner time, or 178m01s cumulative
including the failed 27m39s preparation pair. Both arms stayed below their
120-minute caps. Preparation through first clean dispatch was about 60m05s versus
68m35s; most of the 9m28s wall-time difference existed before the first reset,
so it cannot be attributed to fresh-name reset performance.

Interpretation: the control did not reproduce the fault, and neither did the
treatment. This one W1 pair therefore does not demonstrate that database-name
reuse causes the NRE or that unique names fix it. The source W1 comparator also
passed this prefix. No root-cause/fix claim, merge recommendation, retry, or
additional experiment is implied.

[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.