Note that Newtonsoft serialization attributes stop working after migration

[Fabian (fzankl)]

Follow-up to the AllowSynchronousIO clarification in #128726 and the Migrate to asynchronous HTTP stream I/O section that was added alongside it. That async guidance is correct as written: replacing ReadToEnd with ReadToEndAsync keeps the same serializer, so a migrated app keeps behaving identically. This PR covers a step of the migration that isn't behavior-preserving.

Problem

The in-process model used Newtonsoft.Json. The isolated worker model uses System.Text.Json by default. Types that a migrated app binds to usually still carry Newtonsoft.Json attributes ([JsonProperty("customer_name")] being the common one), and System.Text.Json doesn't recognize them. It binds the affected property to its default value and reports nothing: HTTP 200, property null, no exception and no log entry.

The JSON serialization section of this guide covers the serializer switch itself and links to Customizing JSON serialization for options and for moving back to JSON.NET. It says nothing about the attributes already sitting on the reader's types. JsonProperty and JsonPropertyName currently appear nowhere in this guide, its includes, or dotnet-isolated-process-guide.md, so a reader whose property silently stops binding has nothing to search for.

Measured on Microsoft.Azure.Functions.Worker 2.52.0, Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore 2.1.1, Core Tools 4.13.0, host 4.1051.300.26316: a DTO carrying [JsonProperty("customer_name")] binds to null on every input path tested while the app stays on System.Text.Json, with no diagnostic on any of them.

Change

One file, one added paragraph, nothing removed: note that Newtonsoft.Json serialization attributes carried over from the in-process model are ignored by System.Text.Json without an error. The paragraph gives the two ways out: replace them with their System.Text.Json equivalents, or configure Newtonsoft.Json for the layer that handles the payload.

Notes for review

The edited file is an include, includes/functions-dotnet-migrate-isolated-other-code-changes.md. It renders inside articles/azure-functions/migrate-dotnet-to-isolated-model.md, which is also the file changed by my open PR #128730. The two touch different files and don't conflict, but they land on the same rendered page, so you may want to look at them together.

"Configure Newtonsoft.Json for the layer that handles the payload" is deliberately unspecific about which layer, because that depends on whether the app uses ASP.NET Core integration. There's a companion change for articles/azure-functions/dotnet-isolated-process-guide.md that makes that distinction precise; it's a different file with a different owner, so I'm submitting it separately. Either change stands on its own.

[prmerger-automator]

Fabian (@fzankl) : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[prmerger-automator]

Fabian (@fzankl) : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit d5d6fa5:

✅ Validation status: passed

File	Status	Preview URL	Details
includes/functions-dotnet-migrate-isolated-other-code-changes.md	✅Succeeded

For more details, please refer to the build report.

[Regan Downer (v-regandowner)]

Matthew Henderson (@mattchenderson)

Can you review the proposed changes?

IMPORTANT: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team