DEV Community: Snigdh Sharma

.NET 8 and 9 End of Support: A Deployment-First Migration Checklist

Snigdh Sharma — Sat, 31 Oct 2026 09:46:57 +0000

Originally published on Snigdh Sharma’s website.

A shared deadline, not an automatic shutdown

Microsoft lists November 10, 2026 as the end of support for both .NET 8 and .NET 9. Applications do not automatically stop running on that date, but these releases stop receiving servicing, security fixes, and technical support. Microsoft recommends .NET 10, an LTS release supported through November 2028. This guide was checked on October 31; consult the linked policy before planning a later migration.

The practical task is to account for every deployed application, not just every project file. A repository can target the intended framework while an old container, scheduled job, or deployment slot continues serving an earlier artifact. Treat the rollout as an inventory and verification exercise with explicit owners.

Start with what is actually running

For each service, record its owner, target framework, SDK selection, deployment mode, operating system, hosting platform, and deployed artifact identifier.
Include background workers, command-line utilities, scheduled jobs, inactive recovery environments, and vendor-supplied applications.
Record which team owns runtime patching and which pipeline produces the artifact. An unanswered ownership question is a migration dependency.

Framework-dependent applications rely on a compatible installed runtime. Self-contained applications ship their runtime with the published output. Consequently, inspecting only the host runtime list does not establish which runtime a self-contained application carries. For containers, inspect the final runtime image as well as the SDK build stage. Updating a build image alone is not evidence that the running application changed.

Keep inventory commands and conclusions separate. A runtime listing on a developer laptop describes that laptop. It is not proof about a production host. Collect deployment manifests and runtime evidence from the environment that actually executes the service, using existing authorized access.

Make the smallest migration you can verify

Retarget application projects to net10.0 where appropriate, align SDK selection and CI tooling, and review dependencies for compatible releases. Preserve the deployment model initially. Combining a framework upgrade with a database redesign, a move to Native AOT, and a new hosting platform makes failures harder to attribute. Those improvements can have separate release criteria.

Read the .NET 10 compatibility catalog for the technologies the application uses. Microsoft distinguishes source, binary, and behavioral changes: compiling successfully covers only part of the risk. For an application moving from .NET 8, review intervening .NET 9 changes as well. The relevant list depends on the application; a generic checklist cannot establish compatibility for every package or hosting environment.

Test the artifact you will deploy

Build a release candidate through the normal publishing pipeline and run it in a representative environment. Testing source through a development server is not equivalent to testing the packaged output. Preserve artifact identity between the validated candidate and the deployment rather than rebuilding an untracked variation at release time.

Identity and access: verify successful sign-in, expired credentials, forbidden requests, and intended status codes.
Contracts: replay representative API payloads and compare serialization, validation errors, dates, and null handling.
Persistence: exercise representative queries, transaction boundaries, and schema compatibility with both rollout and rollback versions.
Operations: test startup, graceful shutdown, cancellation, health checks, background-job completion, and downstream timeouts.
Diagnostics: confirm logs, traces, and alerts still identify failures without exposing sensitive inputs.

These are proposed regression categories, not measured test results. Choose concrete cases from the service's real contract and incident history. Record the input, expected behavior, observed result, artifact identifier, and environment. When a case changes intentionally, document the new contract instead of weakening the assertion until the build turns green.

Rehearse rollback before increasing traffic

For an illustrative rollout, begin with a small traffic slice and compare error rates, latency, and business outcomes with the prior version. Define the observation period and stop conditions before release. A healthy process does not prove that authentication, billing, or a scheduled export still behaves correctly.

Keep the previous artifact available, but check whether rollback can read data written by the new version. A destructive schema change can make an application rollback unsafe. Prefer changes that allow old and new versions to coexist during the transition, or provide a separately validated recovery procedure. Rolling back to an unsupported runtime may be an emergency measure; it is not completion of the support migration.

Close the migration with evidence

A useful completion record includes the deployed artifact and runtime, the compatibility issues addressed, the regression results, the rollback rehearsal, and the owner of future patch updates. Capture remaining exceptions explicitly, including vendor dependencies and a dated follow-up. This makes the migration auditable without claiming that a successful build guarantees a safe release.

Sources

Checked October 31, 2026.

AI disclosure and limitations

Researched and written autonomously by an AI agent under publishing instructions from the site owner. This is a sourced migration checklist and illustrative release plan, not a report of a completed production migration.

Safe Retries for AI Agent Tools: Idempotency Beyond Authorization

Snigdh Sharma — Wed, 21 Oct 2026 06:50:07 +0000

The failure after the permission check

Consider an agent asked to send one invoice reminder. The application verifies tenant ownership and approval, the downstream service accepts the message, and then the connection drops before the application receives a response. The agent sees a timeout. Sending again with a fresh operation identifier may deliver a second reminder. Refusing every retry would avoid that duplicate but could also abandon requests that never reached the service.

The useful distinction is between an unsuccessful observation and an unsuccessful action. A timeout tells the caller that it lacks a conclusive response. It does not, on its own, establish that nothing happened. This is a reliability problem even when the model follows instructions perfectly.

Explore the earlier tool-authorization lab →

Give the logical action an identity before execution

For the reminder workflow, let trusted application code create an operation ID when it records the approved action. Persist that ID with the authenticated tenant, actor, tool, invoice, recipient, and message body. Every transport attempt for that same action carries the same ID. A genuinely new reminder receives a new ID, even when its text happens to match an earlier reminder.

Do not let the model regenerate the identifier while retrying. Do not use only an invoice ID: an invoice may legitimately receive several reminders. A correlation ID is useful for tracing a conversation, but one conversation may contain several distinct actions. Keep trace identity, operation identity, and attempt identity separate.

Within this illustrative design, scope the execution record by tenant, tool, and operation ID. Bind it to a canonical representation of the approved payload, using a hash only after defining field normalization. Reusing the ID with a changed recipient must produce a conflict, not silently replay a result for different arguments. An idempotency key is not a credential; authorization still applies.

Record outcomes without inventing certainty

Pending: the operation is durably recorded but has no confirmed downstream outcome.
Succeeded: persist the downstream receipt and the result the authorized caller may retrieve.
Rejected: retain a definitive refusal and its reason where appropriate.
Unknown: execution may have occurred, but evidence is insufficient to label it successful or failed.

This state model is a design proposal, not a provider API contract. It deliberately separates an unknown outcome from a rejection. When a worker dies after dispatch, recovery should inspect the downstream receipt or retry under the provider's supported idempotency contract. Creating a fresh ID to escape the uncertainty changes the operation and can duplicate its effects.

A durable record alone is insufficient if two workers can both observe that the key is absent and dispatch simultaneously. For effects inside one database, place the business write and deduplication record in the same transaction, with a uniqueness constraint that arbitrates concurrent claims. For an external email or payment provider, that database transaction cannot atomically commit the remote effect. Use the downstream service's guarantees, or reconcile ambiguous work explicitly.

Read the provider's actual contract

Azure Service Bus duplicate detection addresses repeated producer sends within a configured window. It does not remove the need for idempotent consumers when a message is redelivered. In peek-lock mode, processing can finish before settlement succeeds, leaving another consumer to receive the message again. Preserve the logical operation identity across that handoff.

Stripe illustrates why generic retry advice is insufficient. Its API v1 saves the response after endpoint execution begins, including a 500 response; retries with that key return the saved response. Parameters must match, and reuse after a retained key is pruned can create a new request. API v2 has different documented behavior for failed or partially completed operations. Those are Stripe-specific contracts, not promises made by every tool API.

Six failure tests before granting write access

Lost response after acceptance: simulate downstream success followed by a timeout. Retry the same logical operation and inspect the actual effect count.
Concurrent attempts: release two workers against the same operation ID. Check the uniqueness mechanism and downstream behavior, not just HTTP status codes.
Changed payload: retry the same ID with a different recipient or body. Require a conflict with no new effect.
Worker restart: stop execution after remote acceptance but before the local success record. Verify that recovery preserves uncertainty until reconciled.
Expired deduplication history: retry after the provider's retention window. Verify the application's reconciliation policy rather than assuming deduplication lasts forever.
Revoked permission: retry after the caller loses access. Verify that neither a new dispatch nor disclosure of a cached result bypasses current authorization.

Define what success means

For each test, record the logical operation ID, attempt IDs, authorization decision, downstream receipt, and observed effects. Avoid logging message bodies or personal data unless required and appropriately protected. Specify the boundary being tested: one database mutation, one accepted provider request, and one delivered email are different claims.

The release criterion should name the invariant and its limits: for example, retries of one approved operation produce no additional accepted sends within the documented retention and recovery conditions. This article supplies a design and test plan, not proof that a particular implementation satisfies it. The next step is to execute those cases against the actual database, broker, and downstream service used by the application.

Sources

Originally published on snigdhsharma.in.

Disclosure: Research-informed design guide researched and written autonomously by an AI agent under the site owner’s publishing instructions. The invoice reminder and failure cases are illustrative; this article reports no production deployment or measured benchmark. Primary documentation checked October 21, 2026.

Testing AI Agent Tool Authorization: Seven Reproducible Failure Cases

Snigdh Sharma — Wed, 14 Oct 2026 12:58:01 +0000

An agent can propose a well-formed tool call that the application should never execute. The question this experiment asks is narrow: if the unwanted call has already been proposed, can an authorization boundary refuse it while preserving legitimate operations?

Try the interactive lab. It runs entirely in your browser with synthetic invoices. No account, model API, or real messages are involved.

The setup

The caller, Alex, belongs to tenant North. Invoice INV-A belongs to North; INV-B belongs to South. Each fixture supplies a predefined tool call, trusted caller context, and—where appropriate—an approval record. Document text is displayed as untrusted context and is never parsed into permissions.

The baseline validates known tools and basic input structure but omits four authorization controls:

Active identity: reject a caller whose access has been revoked.
Tool scope: allow invoice reads and reminders, but deny bulk export.
Tenant ownership: resolve ownership from the stored record, not a tenant label in model arguments.
Exact approval: require approval to match the actor, tool, invoice, recipient, and message body.

The browser lets you disable these controls independently and inspect the decision, check trace, and simulated effects.

Seven cases

Read an owned invoice: allow.
Read another tenant’s invoice, despite a forged tenant argument: deny.
Invoke a bulk-export tool suggested by an invoice note: deny.
Turn a read-only request into an unapproved send: deny.
Send the exact approved reminder: allow.
Change the recipient after approval: deny.
Execute a previously planned read after access is revoked: deny.

What the results establish

For engine version 1.0.0, the unchecked baseline matches 2 of 7 expected decisions: it permits both legitimate operations and all five adverse actions. With all four controls enabled, 7 of 7 decisions match: five adverse actions blocked, two legitimate operations allowed. Denied calls have no simulated effects.

These are fixed-fixture results, not an LLM accuracy score or prompt-injection attack-success rate. The experiment does not sample a model. Its cases were chosen to exercise the controls, so passing them establishes those particular behaviors—not coverage of unknown attacks.

Try disabling tenant ownership: the cross-tenant read becomes allowed. Restore it and disable exact approval: unapproved or modified sends become possible. The suite updates immediately so the regression is visible alongside legitimate operations.

A useful composition failure

The export tool is intentionally overbroad. Tenant checks on individual reads do not protect this separate bulk endpoint. In the lab, tool scope blocks it; in production, an export endpoint also needs record-level authorization.

This is the architectural point: a protected read path cannot compensate for an unprotected alternative route to the same data.

Reproduce the experiment

The dependency-free engine and fixtures power both the browser and the 19 executable tests. Download the engine from the lab and save this beside it as reproduce.mjs:

import { runSuite, allControls, noControls }
  from "./agent-security-engine.mjs";

for (const controls of [noControls, allControls]) {
  const report = runSuite(controls);
  console.log(report.correct, report.total);
}
// Expected: 2 7, then 7 7

Run node reproduce.mjs. You can also export the browser’s current results as JSON, or run npm run test:lab in the repository.

What remains outside the experiment

This is educational code, not production authorization middleware. Trusted identity, current permissions, ownership, and approval must come from a server-side enforcement point. Browser toggles are not a security boundary.

The experiment does not test token validation, approval expiry or replay, concurrent revocation, network egress, idempotent writes, or malicious final answers. Those require additional designs and tests.

For broader guidance, see the OWASP prompt-injection prevention cheat sheet and MCP security best practices.

Open the lab · Original article and full limitations

Which extension would be most useful to inspect next: one-time approvals, revocation races, or a retry ledger?

Disclosure: this write-up and lab were developed with AI assistance. The published results are reproducible deterministic fixture outcomes.