feat: dab init defaults runtime.rest.request-body-strict to false

[Copilot]

Why make this change?

dab init generated configs with request-body-strict: true, causing REST endpoints to reject requests with extra/unmapped fields by default. This added friction for new users and modern scenarios where flexible request bodies are preferred.

What is this change?

• ConfigGenerator.cs: Changed the RestRequestBodyStrict defaulting logic from CliBool.False ? false : true to CliBool.True ? true : false — when --rest.request-body-strict is omitted, the generated config now writes false
• RestRuntimeOptions.cs: The record default (RequestBodyStrict = true) is preserved for backward compatibility — existing configs that omit this field continue to behave as before. Rewrote XML doc to be internally consistent: true rejects extraneous/unmapped fields; false allows and ignores them. Includes a note distinguishing the record default (true, for backward compat) from the dab init generated default (false).
• InitOptions.cs: Updated --rest.request-body-strict help text to "(Default: false) When true, rejects extraneous/unmapped fields in the REST request body. When false, allows and ignores them." and replaced the stale preceding code comment with a clear description of both modes.
• Snapshot files and hardcoded expected JSON in ConfigGeneratorTests updated to reflect the new generated default
• config-generators/*.txt: Added --rest.request-body-strict true explicitly to dab init commands in mssql-commands.txt, mysql-commands.txt, postgresql-commands.txt, and dwsql-commands.txt — these scripts regenerate integration test config files during CI builds, and those configs must retain strict mode (true) for integration tests that validate extraneous-field rejection behavior
• ConfigurationTests.TestReadingRuntimeConfigForCosmos.verified.txt: Updated snapshot to set RequestBodyStrict: false to reflect the new default

How was this tested?

• Integration Tests
  • Config-generator command files updated to keep integration test configs in strict mode, preserving all existing integration test behavior (e.g. PutOneTestWithExtraneousFieldsInRequestBody)
• Unit Tests
  • TestRestRequestBodyStrictMode — updated DataRow for the no-flag case to assert false
  • ConfigGeneratorTests.TestSpecialCharactersInConnectionString — updated expected JSON
  • All 30 InitTests snapshots and 7 EndToEndTests snapshots (those that invoke dab init without the flag) updated to RequestBodyStrict: false
  • ConfigurationTests.TestReadingRuntimeConfigForCosmos snapshot updated to RequestBodyStrict: false
  • AddEntityTests and UpdateEntityTests snapshots intentionally unchanged — those use pre-built config strings, not dab init, and correctly reflect the record default of true

Sample Request(s)

dab init --database-type mssql --connection-string "@env('conn')"

Generated dab-config.json runtime section:

"rest": {
  "enabled": true,
  "path": "/api",
  "request-body-strict": false
}

Original prompt

---

This section details on the original issue you should resolve

<issue_title>dab init to default runtime.rest.request-body-strict to false </issue_title>
<issue_description>## What?

When dab init is run, update its behavior to default runtime.rest.request-body-strict to false in the generated config. This will allow REST request bodies to accept and ignore additional fields by default, making development smoother and reducing unexpected errors.

Why?

Currently, dab init in the CLI generates a dab-config.json where the runtime.rest.request-body-strict option defaults to true (strict mode). This means all extraneous/unmapped fields in REST request bodies are rejected by default, including keys. This can cause confusion for new users and adds friction for modern scenarios where flexible request bodies are preferred, especially with C# developers.</issue_description>

<agent_instructions>Introduce as little change as possible</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes dab init to default runtime.rest.request-body-strict to false  #3165

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[Aniruddh25]

@copilot, investigate these failures: https://dev.azure.com/sqldab/fcb212b3-b288-4c9e-b55a-5842a268b16d/_apis/build/builds/18366/logs/26 and fix them

[Copilot]

@copilot, investigate these failures: https://[dev.azure.com/sqldab/fcb212b3-b288-4c9e-b55a-5842a268b16d/_apis/build/builds/18366/logs/26](https://dev.azure.com/sqldab/fcb212b3-b288-4c9e-b55a-5842a268...

The CI failures were caused by the config-generator scripts (mssql-commands.txt, mysql-commands.txt, postgresql-commands.txt, dwsql-commands.txt) calling dab init without --rest.request-body-strict. Since the CLI default changed to false, the CI-regenerated test config files (dab-config.*.json) would have request-body-strict: false, breaking integration tests like PutOneTestWithExtraneousFieldsInRequestBody that depend on strict mode.

Fixed in commit b24e691 by explicitly adding --rest.request-body-strict true to the init command in each of those files. CosmosDB NoSQL is unaffected since it doesn't support REST.

[Aniruddh25]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[Aniruddh25]

@copilot, fix the snapshot ConfigurationTests.TestReadingRuntimeConfigForCosmos.verified.txt by setting the RequestBodyStrict flag to false in the expected snapshot.

[Aniruddh25]

@copilot, fix the snapshot ConfigurationTests.TestReadingRuntimeConfigForCosmos.verified.txt by setting the RequestBodyStrict flag to false in the expected snapshot.

[Copilot]

@copilot, fix the snapshot ConfigurationTests.TestReadingRuntimeConfigForCosmos.verified.txt by setting the RequestBodyStrict flag to false in the expected snapshot.

Fixed in commit 7a3715e — updated ConfigurationTests.TestReadingRuntimeConfigForCosmos.verified.txt to set RequestBodyStrict: false.

[Aniruddh25]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).