Fix: child-config autoentities fails validation with "No entities found" when using data-source-files

[Copilot]

Why make this change?

• Closes [Bug]: autoentities in a child configuration file (referenced via data-source-files) is not recognized — validation fails with "No entities found" #3655
• When a child config (referenced via data-source-files) uses autoentities instead of explicit entities, validation incorrectly fails with "No entities found". The same autoentities block works correctly in the top-level config. This contradicts documented behavior that states every config may satisfy the entities requirement via autoentities.

What is this change?

• Root cause: MsSqlMetadataProvider.GenerateAutoentitiesIntoEntities stores autoentity resolution counts only on the root (merged) RuntimeConfig.AutoentityResolutionCounts. But ValidateEntityPresence checks the child config's own AutoentityResolutionCounts, which is never populated — so the resolved entity count is always 0 for child configs.

• Fix (RuntimeConfigValidator.ValidateRootConfig): Before validating each child config, copy any missing resolution counts from the root config into the child config. This is a no-op when child counts are already populated (e.g. in unit tests that pre-populate them directly).

foreach (KeyValuePair<string, Autoentity> ae in childConfig.Autoentities)
{
    if (!childConfig.AutoentityResolutionCounts.ContainsKey(ae.Key)
        && runtimeConfig.AutoentityResolutionCounts.TryGetValue(ae.Key, out int count))
    {
        childConfig.AutoentityResolutionCounts[ae.Key] = count;
    }
}

How was this tested?

• Integration Tests
• Unit Tests
  • TestChildWithDataSourceAndAutoentitiesResolvingEntitiesIsValid: child config with only autoentities resolving >0 entities (counts stored on root only) passes validation — direct regression test for the bug.
  • TestRootAndChildBothWithAutoentitiesResolvingEntitiesIsValid: both root and child have autoentities, all counts on root, both pass validation.

Sample Request(s)

// dab-config.child.json — previously caused "No entities found" during `dab validate`
{
  "data-source": { "database-type": "mssql", "connection-string": "@env('CONN_B')" },
  "autoentities": {
    "def-b": {
      "patterns": { "name": "b_{object}", "include": [ "dbo.TableTwo" ] },
      "permissions": [ { "role": "anonymous", "actions": [ { "action": "read" } ] } ]
    }
  }
}

dab validate -c dab-config.json  # now passes when child uses autoentities

[azure-pipelines]

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

[RubenCerna2079]

/azp run

[azure-pipelines]

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

[Copilot]

Pull request overview

Fixes a validation gap in DAB’s multi-file configuration flow: when a child config (loaded via data-source-files) uses autoentities without explicit entities, validation could incorrectly fail with “No entities found” because autoentity resolution counts were only tracked on the merged/root config.

Changes:

• Copy missing AutoentityResolutionCounts entries from the merged/root config into each child config prior to per-child validation.
• Add CLI unit tests covering child-only autoentities resolving >0 entities, and combined root+child autoentities with counts stored only on the root.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Core/Configurations/RuntimeConfigValidator.cs	Ensures child-config validation can see autoentity resolution counts produced during metadata initialization on the merged/root config.
src/Cli.Tests/ValidateConfigTests.cs	Adds regression coverage for child configs using autoentities under data-source-files where counts exist only on the root config.

[RubenCerna2079]

/azp run

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[RubenCerna2079]

/azp run

[azure-pipelines]

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

[aaronburtle]

I think this still rejects a valid root-without-data-source configuration.

runtimeConfig.Autoentities is the merged runtime collection, not the set of autoentities declared by the root file. During data-source-files loading, child autoentities are concatenated into this collection while runtimeConfig.DataSource still represents only the root file. As a result, a root with no data source and a valid child containing data-source plus autoentities reaches hasDataSource == false and hasAutoentities == true, so the root error is recorded before this propagation loop runs.

And I dont think the new test reproduces that state: it manually adds the child to ChildConfigs, but it never merges childConfig.Autoentities into rootConfig.Autoentities as the real loader does.

Please validate the root using only entity and autoentity names declared by the root file, and add a file-loading regression test for a root with no data source plus a child whose autoentity resolves at least one entity.

[aaronburtle]

Can child discoveries incorrectly satisfy the root config's entity requirement?

ValidateEntityPresence(runtimeConfig) receives the merged root config, so it counts entities and autoentity results belonging to every data source. For example, if the root's root-ae resolves 0 entities and the child's child-ae resolves 4, the root sums both counts and passes with a total of 4 even though its own data source has nothing to serve. Explicit child entities cause the same problem through config.Entities.Entities.Count.

This violates the documented rule that the root and every child are validated independently. I think we should compute root presence from root-declared entity/autoentity names only, and a negative regression test where the root autoentity resolves 0 while the child autoentity resolves greater than 0 should clear up when this is working properly. The expected result should be one root error and a valid child, correct?

[aaronburtle]

The latest metadata result should be authoritative instead of preserving an existing child value.

The ContainsKey guard makes validation stateful. After one validation, the child contains the copied count. If metadata initialization later updates the root count, a subsequent validation will retain the old child value. For example, a child copied with count 0 will continue failing even if the current root count is 3; the reverse can incorrectly accept an autoentity that now resolves 0.

Please overwrite the child value from the current root result, including removing a stale child value when the root has no result. Preferably, avoid mutating the child entirely and have per-child validation read the authoritative root count dictionary using the child's autoentity definition names.

[aaronburtle]

These tests exercise the propagation loop but do not reproduce the production data-source-files path.

Manually calling rootConfig.ChildConfigs.Add(...) does not perform the other work done by the real loader: child entities and autoentities are merged into the root collections, ownership maps are combined, and metadata providers are created per data source. The missing merge is significant because it hides both the root-without-data-source failure and the case where child discoveries incorrectly satisfy the root.

Please add a regression test that creates actual root and child JSON files, loads them through FileSystemRuntimeConfigLoader, runs metadata initialization and validation, and asserts the per-file result. Since the linked issue also reports missing child-generated entities through MCP, please either add runtime/MCP coverage proving those entities are present or track that runtime behavior separately rather than closing the whole issue with validation-only tests.