Skip to content

[Bug]: Table writes fail (HTTP 500) for entities defined in a linked data-source-files config #3701

Description

@JerryNixon

When

Using a multi-database setup where a root config links a second database config via data-source-files:

# Root config (database 1)
dab init --database-type mssql --connection-string "@env('DAB_SQL_DB1')" --host-mode Development -c dab-config.json
dab add Db1Orders --source dbo.Orders --permissions "anonymous:*" --source.type table -c dab-config.json

# Linked config (database 2)
dab init --database-type mssql --connection-string "@env('DAB_SQL_DB2')" --host-mode Development -c dab-config-db2.json
dab add Db2Customers --source dbo.Customers --permissions "anonymous:*" --source.type table -c dab-config-db2.json

# Link them
dab configure --data-source-files dab-config-db2.json -c dab-config.json

dab start -c dab-config.json

Then send a write to a table entity that is defined in the linked file (dab-config-db2.json):

POST /api/Db2Customers
Content-Type: application/json

{ "Name": "test" }

Expected

The insert succeeds and returns HTTP 201 with the created row, the same as an equivalent table entity defined in the root config. Table writes should work regardless of whether the entity's data source is in the root config or in a linked data-source-files config.

Actual

The request returns HTTP 500 with a generic error:

{
  "error": {
    "code": "UnexpectedError",
    "message": "While processing your request the server ran into an unexpected error.",
    "status": 500
  }
}

The server log shows a KeyNotFoundException keyed by the entity name, thrown in the SQL mutation/insert path:

System.Collections.Generic.KeyNotFoundException: The given key 'Db2Customers' was not present in the dictionary.
   at Azure.DataApiBuilder.Core.Resolvers.BaseQueryStructure..ctor(...)
   at Azure.DataApiBuilder.Core.Resolvers.SqlInsertStructure..ctor(...)
   at Azure.DataApiBuilder.Core.Resolvers.SqlMutationEngine.PerformMutationOperation(...)

Scope / Root cause (confirmed by test)

The failure is positional, not database- or table-specific. Swapping the topology proves it — the same table behaves differently based only on which config file it lives in:

Table In root config In linked data-source-files config
dbo.Categories POST succeeds (200/201) POST fails (500)
dbo.Category POST succeeds (200/201) POST fails (500)

Additional observations:

  • Reads (GET) work for linked-file entities.
  • Stored procedures in linked files work (they use the execute path, not the table-mutation path).
  • Only table mutations (POST/PUT/PATCH/DELETE) on linked-file entities fail.
  • dab validate passes and reports REST paths for all entities across both files.

Impact

In a multi-database DAB instance, tables in any linked (non-root) database are effectively read-only. Only the root database supports table writes.

Metadata

Metadata

Assignees

Labels

configchanges related to configcriCustomer Reported issue

Type

Fields

No fields configured for Bug.

Projects

Status
Todo

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions