fix: clean up failed LightGBM streaming datasets by ranadeepsingh · Pull Request #2662 · microsoft/SynapseML

Rana Singh (ranadeepsingh) · 2026-08-18T11:10:01Z

Summary

This is a partial safety fix for LightGBM streaming Dataset lifecycle defects discovered while investigating issue #2333.

close newly created native training/reference Datasets when streaming initialization or feature naming fails
close newly created native validation Datasets when manual-finish setup, feature naming, row insertion, LGBM_DatasetMarkFinished, or shared-state ownership transfer fails
always release serialized-reference native byte arrays and void** output containers
preserve the primary initialization error when cleanup also fails
add deterministic ownership/error tests and a synthetic public-estimator repeated-fit test with validation data

Refs #2333

Established concurrency finding

SynapseML intentionally shares one executor-local native streaming Dataset across partition tasks. Each task pushes rows using a distinct external thread index. Upstream LightGBM derives its internal push-buffer index from both that external index and the caller thread's OpenMP thread number.

The native allocation is sized using maxStreamingOMPThreads, but SynapseML cannot prove from numThreads, Spark executor cores, spark.task.cpus, or TaskContext what OpenMP team size every native caller thread will actually use. Therefore this PR does not add a speculative fail-fast check, globally lock ingestion, or force one executor core. Those approaches would reject or serialize configurations without establishing the native safety invariant.

Scope and performance

This PR fixes independently provable native ownership leaks only. It does not claim to resolve the SIGSEGV/SIGBUS/double-free concurrency failure reported in #2333.

No row-push or micro-batch hot path changes. Cleanup is limited to Dataset creation/initialization failures and temporary serialized-reference buffers.

Validation

Local toolchains:

Spark 3.5.0 / Scala 2.12.17 / OpenJDK 11.0.31
Spark 4.1.1 / Scala 2.13.17 / OpenJDK 17.0.19
sbt 1.10.11

Passed locally:

ReferenceDatasetUtilsSuite (moved to lightgbm.split1): 5/5 on Spark 3.5/Scala 2.12 and Spark 4.1/Scala 2.13, including deterministic insertion- and MarkFinished-failure cleanup
StreamingDatasetLifecycleSuite: 1/1; two public LightGBMClassifier.fit() calls with streaming mode, validation data, cached reference reuse, prediction, and cleanup
Spark 3.5/Scala 2.12: lightgbm/compile and lightgbm/Test/compile
Spark 4.1/Scala 2.13/JDK 17 compatibility replay: lightgbm/Test/compile
PipelineTestCoverageSuite: 1/1 on both Spark 3.5 and Spark 4.1
lightgbm/scalastyle and lightgbm/Test/scalastyle on both Spark 3.5 and Spark 4.1
lightgbm/codegen
generated LightGBM Python wrapper compileall
black --check --extend-exclude 'docs/' . (194 files unchanged)
git diff --check

Residual risk / required validation

Real multi-core executor validation on Fabric or equivalent native Linux infrastructure is still required to reproduce and resolve the original crash safely. Local validation exercised local[*] Spark scheduling but intentionally used one LightGBM task and one native thread for deterministic lifecycle coverage; it is not evidence that the native concurrency crash is fixed.

Azure build 231682017 passed all LightGBM unit shards, Python/R LightGBM, Fabric E2E, Databricks E2E, publish, Docker, and style. Its Spark 4.1 test-compile and matrix-coverage failures are addressed by the current head; Search1 was canceled after the build had already failed. No Azure rerun was triggered by this update.

Refs microsoft#2333 ## Summary Clean up native LightGBM Dataset handles and SWIG pointer buffers when streaming Dataset creation or initialization fails. Add deterministic ownership tests and a synthetic public-estimator repeated-fit test with validation data. ## Prompting Intent Fix the independently established native Dataset cleanup leak related to SynapseML issue microsoft#2333 without guessing at a concurrency invariant, globally serializing ingestion, or disabling supported multi-core configurations. Exercise success, failure, cleanup-failure, validation Dataset, cached-reference, prediction, and repeated-fit paths. ## Linked Sources - SynapseML issue microsoft#2333: microsoft#2333 - LightGBM streaming Dataset support: lightgbm-org/LightGBM#5299 - LightGBM caller-thread OpenMP investigation: lightgbm-org/LightGBM#5551 - Repository guidance: AGENTS.md ## Rationale Use ownership-scoped failure cleanup around newly created native Datasets and unconditional deletion for temporary SWIG allocations. This preserves normal successful ownership and avoids hot-path locking. No Spark-side fail-fast guard is added because maxStreamingOMPThreads, numThreads, executor cores, spark.task.cpus, and TaskContext do not establish the actual OpenMP team size on every native caller thread. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

azure-pipelines · 2026-08-18T11:10:11Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

github-actions · 2026-08-18T11:13:06Z

Hey Rana Singh (@ranadeepsingh) 👋!
Thank you so much for contributing to our repository 🙌.
Someone from SynapseML Team will be reviewing this pull request soon.

We use semantic commit messages to streamline the release process.
Before your pull request can be merged, you should make sure your first commit and PR title start with a semantic prefix.
This helps us to create release messages and credit you for your hard work!

Examples of commit messages with semantic prefixes:

fix: Fix LightGBM crashes with empty partitions
feat: Make HTTP on Spark back-offs configurable
docs: Update Spark Serving usage
build: Add codecov support
perf: improve LightGBM memory usage
refactor: make python code generation rely on classes
style: Remove nulls from CNTKModel
test: Add test coverage for CNTKModel

To test your commit locally, please follow our guild on building from source.
Check out the developer guide for additional guidance on testing your change.

Refs microsoft#2333 ## Summary Extend validation Dataset ownership cleanup through row insertion, native MarkFinished, and shared-state ownership transfer. Add deterministic insertion- and finish-failure tests that verify one close, no premature ownership transfer, and preservation of the primary exception. ## Prompting Intent Address the concrete lifecycle gap found during review of draft PR microsoft#2662 without expanding the PR's concurrency claim. Ensure a native validation Dataset cannot leak when insertion or finalization fails before shared-state ownership is assigned. ## Linked Sources - SynapseML issue microsoft#2333: microsoft#2333 - Draft PR microsoft#2662: microsoft#2662 - Parent lifecycle review finding on PR microsoft#2662 - Repository guidance: AGENTS.md ## Rationale Keep the cleanup boundary ownership-scoped: the newly created validation Dataset is closed on any failure through insertion, MarkFinished, or ownership transfer, while successful shared-state ownership preserves existing cleanup behavior. Reuse the primary-exception-preserving Dataset helper rather than introducing native mocks, ingestion locks, or concurrency policy changes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Rana Singh (ranadeepsingh) · 2026-08-18T15:37:52Z

/azp run

azure-pipelines · 2026-08-18T15:38:07Z

Azure Pipelines: Successfully started running 1 pipeline(s).

Refs microsoft#2333 ## Summary Move ReferenceDatasetUtilsSuite into the claimed LightGBM split1 package and wrap assignment-expression by-name arguments in braces for Scala 2.13 compatibility. ## Prompting Intent Fix the two concrete product/test-integration failures from Azure build 231682017 on draft PR microsoft#2662: Spark 4.1 test compilation and PipelineTestCoverageSuite matrix coverage. Preserve all lifecycle regression coverage without editing pipeline.yaml or expanding the concurrency claim. ## Linked Sources - SynapseML issue microsoft#2333: microsoft#2333 - Draft PR microsoft#2662: microsoft#2662 - Azure build 231682017 - Repository guidance: AGENTS.md ## Rationale Use the existing lightgbm.split1 matrix claim rather than adding pipeline configuration. Braced assignment bodies compile under both Scala 2.12 and 2.13 while retaining the deterministic by-name execution assertions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Rana Singh (ranadeepsingh) · 2026-08-18T17:47:51Z

/azp run

azure-pipelines · 2026-08-18T17:48:05Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-08-18T18:59:09Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

Copilot

Pull request overview

This PR addresses native LightGBM streaming Dataset lifecycle leaks by ensuring newly created native training/reference/validation datasets and temporary native buffers are reliably cleaned up when initialization steps fail, while preserving the original (primary) exception if cleanup also fails. It adds targeted tests to make these failure/ownership scenarios deterministic and to validate repeated fit() calls with streaming + validation data.

Changes:

Introduce a shared initializeOwnedDataset helper to run initialization with “cleanup on failure while preserving the primary error” semantics.
Refactor streaming validation-dataset creation to only store the dataset in shared state after successful insertion/finish/ownership transfer, with cleanup on intermediate failures.
Ensure native resources used during serialized-reference deserialization (byte[] native buffer and void** handle) are always released, and add deterministic lifecycle tests.

Show a summary per file

File	Description
lightgbm/src/main/scala/com/microsoft/azure/synapse/ml/lightgbm/StreamingPartitionTask.scala	Refactors validation dataset creation to centralize failure-safe initialization/cleanup and delay shared-state ownership until success.
lightgbm/src/main/scala/com/microsoft/azure/synapse/ml/lightgbm/dataset/ReferenceDatasetUtils.scala	Adds `initializeOwnedDataset` and ensures cleanup of native buffers/handles during reference dataset initialization/deserialization.
lightgbm/src/test/scala/com/microsoft/azure/synapse/ml/lightgbm/split1/ReferenceDatasetUtilsSuite.scala	Adds deterministic unit tests validating cleanup-on-failure semantics and suppressed-exception preservation.
lightgbm/src/test/scala/com/microsoft/azure/synapse/ml/lightgbm/split1/StreamingDatasetLifecycleSuite.scala	Adds an end-to-end repeated-fit test for streaming mode with validation data and cached reference reuse.

Review details

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Files reviewed: 4/4 changed files
Comments generated: 0
Review effort level: Lite

## Summary Collapse validation serving completion and cleanup into one bounded close operation, remove per-transfer Future retention and per-partition row-count maps, preserve stream cleanup failures, and validate protocol versions and partition IDs. ## Prompting Intent Perform an adversarial simplicity and maintainability audit of PR microsoft#2664 after its review fixes. Remove avoidable lifecycle machinery, prove disk/network/thread bounds remain explicit, preserve exact validation semantics and compatibility, and verify the required merge composition with PR microsoft#2662. ## Linked Sources - Issue: microsoft#2294 - Pull request: microsoft#2664 - Overlapping lifecycle pull request: microsoft#2662 - Exact-head automated review on b5b1ce6 ## Rationale A single close boundary can stop acceptance, close active sockets, terminate the fixed executor, surface serving failures, and delete the spool without a separate await phase or unbounded Future queues. Semaphore ownership provides a constant-memory ingest completion barrier. Driver disk and complete per-worker network transfer remain intentionally linear because native LightGBM requires every native validation Dataset to contain the exact full validation set; sampling, sharding, or persistent Spark file distribution would change semantics or leak large files. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Refs #2333 ## Summary Extend validation Dataset ownership cleanup through row insertion, native MarkFinished, and shared-state ownership transfer. Add deterministic insertion- and finish-failure tests that verify one close, no premature ownership transfer, and preservation of the primary exception. ## Prompting Intent Address the concrete lifecycle gap found during review of draft PR #2662 without expanding the PR's concurrency claim. Ensure a native validation Dataset cannot leak when insertion or finalization fails before shared-state ownership is assigned. ## Linked Sources - SynapseML issue #2333: #2333 - Draft PR #2662: #2662 - Parent lifecycle review finding on PR #2662 - Repository guidance: AGENTS.md ## Rationale Keep the cleanup boundary ownership-scoped: the newly created validation Dataset is closed on any failure through insertion, MarkFinished, or ownership transfer, while successful shared-state ownership preserves existing cleanup behavior. Reuse the primary-exception-preserving Dataset helper rather than introducing native mocks, ingestion locks, or concurrency policy changes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Add a manifest-driven fabric-spark-cli runner, reusable scenarios, and an Azure Pipeline gate that executes exact SynapseML core and cognitive artifacts on a managed Fabric Spark runtime. Cover OpenAIPrompt behaviors derived from PySpark AI Functions and retain JUnit, provenance, diagnostics, and cleanup evidence. ## Prompting Intent The engineer asked for a reusable way to remove uncertainty from SynapseML bug fix and feature pull requests by running their exact artifacts end to end on Fabric. They specifically requested a pipeline scenario that exercises the public OpenAIPrompt PySpark primitive with AI Functions-inspired cases, without injecting OpenAI credentials. ## Linked Sources - Motivating pull request: #2662 - No standalone requirements or design specification; the implementation follows the engineering conversation and repository contribution guidance. ## Rationale Use Fabric platform notebooks for OpenAIPrompt because direct batch submission does not provide the workload-operation context required by Fabric's implicit LLM endpoint. Side-load exact package jars and record hashes and class sources so a passing run proves the proposed JVM implementation was exercised. Keep credentials out of scenario arguments, skip untrusted forks, and delete unique scratch notebooks and lakehouses in finally paths. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Reduce the Fabric E2E change to one dedicated OpenAIPrompt notebook gate. Remove the generic manifest, batch execution path, unrelated LightGBM and smoke scenarios, and repository skill while preserving exact-jar provenance, structured evidence, and cleanup. ## Prompting Intent The engineer asked to correct an overcomplicated pull request that conflated the LightGBM motivation from PR #2662 with the OpenAIPrompt behavior actually run by the pipeline. The resulting PR must state and test only OpenAIPrompt. ## Linked Sources - Pull request: #2669 - Original LightGBM example: #2662 - Trusted baseline run: https://msdata.visualstudio.com/A365/_build/results?buildId=231855072 ## Rationale Keep the proven platform-notebook and OneLake marker path because the build service identity cannot read executed-notebook snapshots. Remove every scenario and abstraction not used by the OpenAIPrompt pipeline job so the title, implementation, tests, and retained evidence describe the same scope. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Restore the manifest-driven Fabric runner, agent skill, runtime smoke, jar provenance, LightGBM streaming, and OpenAIPrompt scenarios. Keep OpenAIPrompt as the trusted pipeline gate while making every scenario directly runnable by agents with exact PR artifacts and retained evidence. ## Prompting Intent The engineer clarified that PR #2669 must cover LightGBM and other Fabric E2E cases in addition to OpenAIPrompt. The PR title, description, implementation, and evidence must present the complete reusable framework rather than framing the entire change as an OpenAIPrompt-only gate. ## Linked Sources - Pull request: #2669 - LightGBM motivating pull request: #2662 - Trusted OpenAIPrompt run: https://msdata.visualstudio.com/A365/_build/results?buildId=232078819 ## Rationale Use one manifest and runner for batch and notebook profiles so agents share artifact provenance, cleanup, JSON, and JUnit behavior. Automate OpenAIPrompt in trusted CI because it requires platform-notebook workload context; retain the other scenarios for targeted module validation. The LightGBM lifecycle profile uses one feature so the repeated streaming-fit path is not masked by the separate multi-feature reference-dataset naming defect found on Fabric. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Collapse validation serving completion and cleanup into one bounded close operation, remove per-transfer Future retention and per-partition row-count maps, preserve stream cleanup failures, and validate protocol versions and partition IDs. ## Prompting Intent Perform an adversarial simplicity and maintainability audit of PR microsoft#2664 after its review fixes. Remove avoidable lifecycle machinery, prove disk/network/thread bounds remain explicit, preserve exact validation semantics and compatibility, and verify the required merge composition with PR microsoft#2662. ## Linked Sources - Issue: microsoft#2294 - Pull request: microsoft#2664 - Overlapping lifecycle pull request: microsoft#2662 - Exact-head automated review on b5b1ce6 ## Rationale A single close boundary can stop acceptance, close active sockets, terminate the fixed executor, surface serving failures, and delete the spool without a separate await phase or unbounded Future queues. Semaphore ownership provides a constant-memory ingest completion barrier. Driver disk and complete per-worker network transfer remain intentionally linear because native LightGBM requires every native validation Dataset to contain the exact full validation set; sampling, sharding, or persistent Spark file distribution would change semantics or leak large files. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Declare the three rebased commits from merged PR microsoft#2662 as release-compatibility prerequisites so the Spark 4.1 replay receives the Dataset ownership helpers before applying PR microsoft#2664. ## Prompting Intent Rebase PR microsoft#2664 onto the current master branch and make every engineering gate reproducibly green, including the repository's Spark 4.1 release-compatibility replay. ## Linked Sources - Issue: microsoft#2294 - Pull request: microsoft#2664 - Prerequisite pull request: microsoft#2662 - Release compatibility gate: https://github.com/microsoft/SynapseML/blob/master/pipeline.yaml ## Rationale PR microsoft#2664 composes PR microsoft#2662's ownership-scoped validation Dataset initialization, while Spark 4.1 has not yet received that merged master change. The compatibility job applies each configured commit's first-parent patch, so all three rebased PR microsoft#2662 commits are listed in order rather than only its final GitHub merge OID. Applying the prerequisites first makes the PR patch conflict-free and preserves the exact code that passed Spark 4.1 test compilation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Terminate the release-compatibility prerequisite configuration with a standard final newline. ## Prompting Intent Finish PR microsoft#2664 with a clean, review-ready diff after adding the Spark 4.1 compatibility prerequisites. ## Linked Sources - Pull request: microsoft#2664 - Prerequisite pull request: microsoft#2662 ## Rationale The compatibility parser explicitly tolerates an unterminated final record, but a newline-terminated text file avoids persistent diff annotations and works consistently with standard repository tooling. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Request a Fabric-scoped access token when the legacy E2E suite discovers its workspace, and add deterministic coverage for token configuration and workspace response handling. ## Prompting Intent Investigate and fix the failing SynapseML Fabric E2E pipeline in an isolated worktree, following the PR readiness loop without suppressing required failures or weakening runtime evidence. ## Linked Sources - Pull request: #2669 - Fabric validation request: #2662 - Failed PR build: https://msdata.visualstudio.com/A365/_build/results?buildId=232324496 - Failed isolated probe: https://msdata.visualstudio.com/A365/_build/results?buildId=232331735 - Fabric REST scopes: https://learn.microsoft.com/rest/api/fabric/articles/scopes ## Rationale The shared test client intentionally acquires a Power BI token for Power BI and MWC endpoints, but workspace discovery calls the public Fabric REST endpoint. Requesting the documented Fabric scope only for that call fixes the audience mismatch while preserving all existing Power BI authentication behavior. The failure remains blocking if token acquisition, workspace lookup, or response validation fails. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

## Summary Resolve the legacy integration workspace through the Power BI Groups API, matching the certificate client token and preserving strict workspace response validation. ## Prompting Intent Continue investigating the required Fabric E2E failure after a Fabric-scoped token still received HTTP 500, and deliver a managed-runtime fix without making the legacy gate advisory or suppressing its failures. ## Linked Sources - Pull request: #2669 - Failed scoped-token build: https://msdata.visualstudio.com/A365/_build/results?buildId=232335698 - Power BI Get Groups API: https://learn.microsoft.com/rest/api/power-bi/groups/get-groups - Fabric validation request: #2662 ## Rationale The certificate client is designed around a Power BI access token. The public Fabric workspace endpoint returned HTTP 500 with both its original token and a Fabric-scoped token, while the documented Power BI Groups endpoint exposes the same workspace IDs using the token the client already owns. Keeping lookup on that matching API avoids broad authentication changes and leaves every later Fabric operation and failure condition intact. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AB#5538675 ## Summary Replace the failing legacy Power BI and certificate-based Fabric test path with Azure CLI authentication, public Lakehouse lifecycle APIs, and fabric-spark-cli direct batches. Build and side-load the exact core jar, verify its SHA-256 in every managed notebook, retain logs, cancel failed batches, and hard-delete controlled test artifacts. Preserve structured runner evidence when execution or cleanup raises unexpectedly. ## Prompting Intent Investigate PR #2669's failing SynapseML Fabric E2E pipeline in an isolated worktree and follow the SynapseML PR readiness loop. Keep smoke coverage and all five notebook tests blocking, preserve deterministic cleanup, prove the exact checkout runs on Fabric, and maintain spark4.1 release compatibility. ## Linked Sources - Pull request: #2669 - Original Fabric E2E gap: #2662 - Pipeline failure: https://msdata.visualstudio.com/b9b2accc-2d1c-45b3-9d24-0eb5d78cc47f/_build/results?buildId=232398344 - Tracking work item: https://msdata.visualstudio.com/b9b2accc-2d1c-45b3-9d24-0eb5d78cc47f/_workitems/edit/5538675 - Suppressed review findings: #2669 (review) ## Rationale Direct CLI batches use the supported per-run jar upload and classpath path, whereas Spark Job Definitions reject jar libraries and temporary Fabric Environment publication repeatedly timed out. Public Lakehouse APIs keep resource ownership explicit, and runtime hashing proves Fabric loaded the locally built jar rather than a bundled version. Azure CLI-specific logic lives in a new helper so divergent legacy authentication files remain unchanged in the net PR patch and replay cleanly onto spark4.1. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AB#5538675 ## Summary Stage a uniquely named, byte-identical SynapseML core jar for every direct Fabric batch so concurrent fabric-spark-cli processes upload to distinct OneLake objects. Preserve runtime SHA-256 provenance and clean every temporary script and jar, including when an earlier cleanup operation fails. ## Prompting Intent Investigate PR #2669's failing SynapseML Fabric E2E pipeline in an isolated worktree and follow the SynapseML PR readiness loop. Fix the exact-head concurrency failure without reducing the three-notebook parallelism, weakening exact-jar verification, or regressing master and spark4.1 compatibility. ## Linked Sources - Pull request: #2669 - Original Fabric E2E gap: #2662 - Failing exact-head build: https://msdata.visualstudio.com/b9b2accc-2d1c-45b3-9d24-0eb5d78cc47f/_build/results?buildId=232406734 - Tracking work item: https://msdata.visualstudio.com/b9b2accc-2d1c-45b3-9d24-0eb5d78cc47f/_workitems/edit/5538675 ## Rationale The failed batches concurrently appended the same jar basename in OneLake. Unique per-batch basenames remove that remote-object race while retaining the existing bounded concurrency. Staging copies is safer than serializing all notebooks or changing fabric-spark-cli internals; the in-process digest check still proves each copied jar matches the locally built artifact. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AB#5538675 ## Summary Route FabricTestConstants workspace resolution through the shared Azure CLI configuration so pipeline-provided INTEGRATION_WORKSPACE_ID values bypass credential-era account discovery. Preserve the existing credential discovery fallback and add regression coverage for lazy, explicit workspace resolution. ## Prompting Intent Investigate PR #2669's failing SynapseML E2E pipeline in an isolated worktree and follow the SynapseML PR readiness loop. Triage every exact-head failure, fix product and test defects without restoring retired certificate authentication, and preserve master and spark4.1 compatibility. ## Linked Sources - Pull request: #2669 - Original Fabric E2E gap: #2662 - Exact-head compatibility failure: https://msdata.visualstudio.com/b9b2accc-2d1c-45b3-9d24-0eb5d78cc47f/_build/results?buildId=232412561 - Tracking work item: https://msdata.visualstudio.com/b9b2accc-2d1c-45b3-9d24-0eb5d78cc47f/_workitems/edit/5538675 ## Rationale SynapseML-Internal accesses FabricTestConstants directly, so exporting an explicit workspace ID in the pipeline did not reach the newer notebook helper and instead triggered missing INTEGRATION_ACCOUNT errors. Reusing the shared resolver fixes every caller, retains GUID validation and legacy discovery, and avoids reintroducing certificate secrets or private-repository special cases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>