DEV Community: MICHAEL-MAURICE

My Sale Ended at the Wrong Midnight: 6 Bugs in Time-Limited Discount Codes in .NET

MICHAEL-MAURICE — Sat, 31 Oct 2026 16:19:37 +0000

"40% off until Sunday" sounds like one if statement. Then a customer in another time zone gets refused at 11 PM their time, a $9.99 item charges $5.99 on one screen and $6.00 on another, and a monthly plan keeps the discount forever because nobody decided what "until Sunday" means for a subscription.

I'm running exactly this kind of promo right now, so here are the six bugs I check for whenever a time-limited code goes into a .NET checkout. The code below is trimmed to the shape; the trimmed parts are marked.

Tech Skill Builder is $5/month for a very limited time (normally $10). Grab it now before it goes back to $10. And until Sunday, November 2 (end of day, Cairo time), the code HALLOWEEN40 takes 40% off everything in the store, including the membership. See Tech Skill Builder

Bug 1: "End of day" in the server's time zone

DateTime.Now > promo.EndsAt uses whatever zone the server runs in. In a container that's usually UTC, so a Cairo "end of Sunday" ends two hours early.

Store the end as an instant, computed once from the zone the business promised:

var cairo = TimeZoneInfo.FindSystemTimeZoneById("Africa/Cairo");
var endLocal = new DateTime(2026, 11, 2, 23, 59, 59, DateTimeKind.Unspecified);
DateTimeOffset endsAt = TimeZoneInfo.ConvertTimeToUtc(endLocal, cairo); // persist this

Then compare with an injected TimeProvider, never DateTime.Now:

public bool IsActive(Promo p, TimeProvider clock) =>
    clock.GetUtcNow() >= p.StartsAt && clock.GetUtcNow() < p.EndsAt;

TimeProvider also makes the next bug testable with FakeTimeProvider.

Bug 2: Nobody tested the boundary

Write tests for one second before the end, the exact end and one second after. With FakeTimeProvider from Microsoft.Extensions.TimeProvider.Testing that's three lines each. Also test a date across a DST change if your zone has one.

var clock = new FakeTimeProvider(promo.EndsAt.AddSeconds(-1));
Assert.True(service.IsActive(promo, clock));
clock.Advance(TimeSpan.FromSeconds(1));
Assert.False(service.IsActive(promo, clock));

Bug 3: Rounding in three different places

The cart rounds per line, the summary rounds the total, the payment provider rounds again. Pick one rule, use decimal, and round once with an explicit mode:

static long DiscountedCents(long priceCents, int percentOff) =>
    (long)Math.Round(priceCents * (100 - percentOff) / 100m, MidpointRounding.AwayFromZero);

Work in minor units (cents) end to end, and show the customer the same number you charge.

Bug 4: The subscription keeps the discount forever

For a one-off product, "valid until Sunday" is clear. For a monthly plan it's three possible rules: the first payment only, N months, or every cycle for as long as they stay. All three are fine; leaving it undecided is the bug. Model it explicitly:

public enum DiscountDuration { FirstPaymentOnly, Months, Forever }
// ... the promo carries Duration + DurationMonths, and the billing job reads them

And say in the promo text which rule applies.

Bug 5: Max-uses check that races

if (promo.TimesUsed < promo.MaxUses) { ...; promo.TimesUsed++; } lets two parallel checkouts both pass. Make the increment the check:

UPDATE Promos SET TimesUsed = TimesUsed + 1
WHERE Id = @id AND (MaxUses IS NULL OR TimesUsed < MaxUses);
-- 0 rows affected = sold out

In EF Core 10 that's one ExecuteUpdateAsync with the same Where. Do it inside the same transaction as the order, or release the slot when payment fails.

Bug 6: Validating the code only when it's typed

A code is checked when the customer applies it, then the payment page sits open for 40 minutes and the sale ends. Re-validate at the moment you create the payment (or the Stripe Checkout session), not only on "Apply". The same goes for extending a sale: if you move the end date, every place that cached the old one (banners, emails, the validation service) needs the new value.

The short checklist

End time stored as a UTC instant, computed from the zone you promised
TimeProvider everywhere, boundary tests with FakeTimeProvider
One rounding rule, in cents, applied once
Subscription discount duration decided and written down
Atomic max-uses increment
Re-validate when the payment is created

Want the full projects?

The snippets above are skeletons. The complete, tested code is in the store: the Stripe Integration for .NET 10 kit covers checkout and webhooks end to end, and Tech Skill Builder adds a new full-source .NET + AI project with a step-by-step guide every day.

Tech Skill Builder is $5/month for a very limited time (normally $10). Grab it now before it goes back to $10. Until Sunday, November 2 (end of day, Cairo time), the code HALLOWEEN40 takes 40% off everything in the Elite Solutions store.

Which of these six has bitten you? Tell me in the comments.

I Masked the User's Message and the Email Still Left: 7 Places PII Slips Out of a .NET 10 LLM Pipeline

MICHAEL-MAURICE — Sat, 31 Oct 2026 13:00:05 +0000

The idea is simple, and I liked it immediately. Before a chat message goes to the model, swap every email, phone number, IBAN and card for a typed placeholder like [EMAIL_1]. Keep the mapping in a per-conversation vault on your side. When the answer comes back, swap the values back in. The model still knows "this is an email, the same one as before", which is all it needs to call lookup_customer.

I built that as a DelegatingChatClient on Microsoft.Extensions.AI 10.11.0 for a support assistant. Masking the user's message took an afternoon. Then I started checking what actually left the process, and found personal data in places I hadn't thought of as "the prompt" at all.

Here are the seven places, roughly in the order I found them. The code is trimmed to the shape, and the trimmed parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. The complete, working, tested version of this PII shield is inside, with full source and an in-depth PDF guide. Join Tech Skill Builder

Place 1: Round two of function calling

My first version masked user text and rehydrated tool arguments, so lookup_customer got the real email. Correct. Then FunctionInvokingChatClient built the next request to the model. It contained:

the assistant's function call, with the arguments it actually ran with (the real email)
the tool result, raw: the customer's name and phone number

So the second round carried the email back to the provider inside the assistant's own tool call. Masking "the prompt" isn't enough. The shield masks every message on every round: user text, earlier assistant turns, function-call arguments, function results, the instructions, even AuthorName.

Where the shield sits decides most of this:

new ChatClientBuilder(model)
    .UseFunctionInvocation(new CappedLoggerFactory(loggerFactory, LogLevel.Debug))  // outermost: tools get real values
    .UsePiiShield(engine, auditor)                                                    // masks every round
    .UseLogging()                                                                      // innermost: only sees placeholders
    .Build(services);

The first Use is the outermost client. Tools run on your server and need the real email, so function invocation stays outside. Anything the shield can't scan, like an image in a DataContent, is blocked by default, because no regex reads a photo of a passport.

Place 2: Tool results, after JSON escaping

Tool results come back as JSON. The obvious move is to serialize and run your detectors over the string. Here's default System.Text.Json output for a customer called Mariam:

{"name":"\u0645\u0631\u064A\u0645 \u062D\u0633\u0646","phone":"\u002B20 122 555 0199"}

The name is escaped into \u sequences and the plus sign too. A text scan finds 122 555 0199 without the country code, and no name at all. The model decodes the escapes just fine.

Fix: walk the JSON and mask each value on its own, then write the result with the relaxed encoder. The engine's MaskToolResult turns that payload into {"name":"[PERSON_1]","phone":"[PHONE_1]"}. A card sent as a JSON number becomes a token string.

Place 3: Your logs

LoggingChatClient logs full message contents at Trace. Put it inside the shield and Trace shows placeholders. Put it outside and it shows the customer. In the demo I ran both orders on one message: inside, no raw email in the log; outside, the email is right there.

The sneaky one is FunctionInvokingChatClient. It has to stay outside the shield, and at Trace it logs every tool argument and every tool result, raw. A log filter in appsettings.json works until someone edits appsettings.json. I'd rather make it impossible, so that client gets a logger factory that refuses anything below Debug:

public sealed class CappedLoggerFactory(ILoggerFactory inner, LogLevel minimum) : ILoggerFactory
{
    public ILogger CreateLogger(string categoryName) => new Capped(inner.CreateLogger(categoryName), minimum);
    // Capped.IsEnabled(level) => level >= minimum && inner.IsEnabled(level)
    // (the wrapper and the rest of ILoggerFactory are in the complete project)
}

Telemetry is safer by default: OpenTelemetryChatClient.EnableSensitiveData is off unless the OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT environment variable says otherwise. Know that variable exists before somebody sets it on the cluster while debugging.

Place 4: The model's own answer

This leak goes the other way, towards the user's screen. The vault knows the real card number, so a naive "put everything back" step will print it in full if the model writes [CARD_1]. In my demo the offline model tried exactly that: "The card on file is [CARD_1]. You can print it as [CARD_1], written exactly like that."

Fix: a reveal policy decided by the vault entry, never by the model's text:

public static RevealPolicy Default { get; } = new(e => e.Kind switch
{
    PiiKind.Card => Reveal.Partial,                                          // "card ending 1111"
    PiiKind.Iban when !e.Origins.HasFlag(PiiOrigin.User) => Reveal.Partial,  // came from a tool, not the user
    _ => Reveal.Full,
});

The user saw "card ending 1111" twice. A prompt injection can change what the model writes. It can't change what the vault says. Tool arguments are not subject to this policy; tools run on your side and get the real value.

Streaming adds a twist here: the provider decides where chunks end, so [PER and SON_1] can arrive separately. A small StreamingRehydrator holds back only the tail after the last unclosed [, up to the longest placeholder (15 characters), so the user never sees half a token.

Place 5: Placeholders nobody issued

Two cases I didn't plan for:

The user types a token. If someone types [EMAIL_1], it could collide with a real entry. The shield rewrites typed tokens to (EMAIL_1), because the token namespace belongs to the vault.
The model invents a token. Models hallucinate placeholders too. A token the vault never issued, like [EMAIL_99] or one from another conversation, renders as [unavailable] and is counted, so you can alert on it.

Lower-cased tokens like [email_1] still resolve, because models do that. Bare EMAIL_1 without brackets doesn't. Guessing is how one customer's address ends up on another customer's screen.

Place 6: Values the detectors refuse to mask

Detection is deliberately strict: IBANs only when the mod-97 check passes, cards only when Luhn passes. That keeps garbage out of the vault. It also means a customer who types their IBAN with one wrong digit gets it sent to the provider unmasked. It's still somebody's bank account, give or take a digit.

Fix: a second, cruder net after masking. An EgressScanner looks for the shape of personal data in the outbound payload, ignoring placeholders and ISO dates:

public IEnumerable<string> Scan(string text)
{
    // strip placeholders, ISO dates and allow-listed patterns first
    // then report "EmailLike", "IbanLike" and "LongNumber" (9+ digits) findings, names only, never values
    // (full implementation in the complete project)
}

If anything turns up, the request isn't sent. The demo output:

blocked: Outbound request still looks like it contains personal data (IbanLike, LongNumber); not sent.
requests that reached the model: 0

The API answers with a 422 and finding names. The price is false positives like a 12-digit tracking number, which is what the allow-list is for.

Place 7: The audit trail

You'll want to know how much personal data went through and whether it's the same customer as yesterday. The careless version logs the values "for debugging", and now your audit store is the leak.

Fix: record counts per kind and keyed fingerprints instead, using the HMAC redactor from Microsoft.Extensions.Compliance.Redaction:

services.AddRedaction(b => b.SetHmacRedactor(
    o => { o.KeyId = settings.AuditHmacKeyId; o.Key = key; },   // key from your secret store
    new DataClassificationSet(PiiClassifications.Personal)));

The same email gives the same fingerprint in two conversations, and the email itself is never stored. One trap from my spike: NullRedactor returns its input unchanged, so never let it become the fallback for personal data.

What this is not

It's pseudonymization, not anonymization. Under GDPR, data you can re-identify with extra information (your vault) is still personal data (Recital 26). What you get is less exposure: the provider, the logs and the traces see tokens.

Placeholders also break one thing on purpose: dates are personal data too, so by default they become tokens, and then the model can't tell whether an order is inside a 30-day return window. The project includes two ways around that, and the PDF guide covers them in a chapter of its own.

Pre-flight checklist for a PII shield

[ ] Every message is masked on every round, not only the user's text
[ ] Function invocation is outside the shield, logging inside
[ ] Tool results are masked per JSON value, not as escaped text
[ ] The function-invoking client can't log below Debug
[ ] The vault entry, not the model, decides how much the user sees
[ ] Typed tokens are neutralized, unknown tokens resolve to nothing
[ ] An egress scan blocks anything that still looks like personal data
[ ] The audit trail holds counts and HMAC fingerprints, never values

What I tested

The project has 231 passing tests (207 unit, 24 WebApplicationFactory integration tests), including the real OpenAI adapter against a local fake endpoint, and none needs an API key. A 12-scene CLI demo runs every place above against an offline model. The library behaviors I mention were checked with spikes against Microsoft.Extensions.AI 10.11.0 and .NET 10 and are pinned as tests. Names are detected from a list you already have (a CRM, for example), so strangers' names need a NER model as an extra detector.

Get the complete project

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. This project is already inside: the full .NET 10 solution with the detectors, the per-conversation vault, the PseudonymizingChatClient with streaming, the reveal policy, token neutralization, the egress scanner, the capped function-invocation logging, HMAC audit fingerprints, a minimal API with SSE streaming, the demo and all 231 tests, plus a PDF guide that goes much deeper than this post, including the full answer to the date problem, with code. You also get the other complete, tested .NET + AI projects in the membership, with new ones added regularly.

Join Tech Skill Builder for $5/month

Which of these seven would your current setup have missed?

Faking a Yes: 6 Attacks I Ran Against the Human Confirmation in My .NET 10 MCP Server

MICHAEL-MAURICE — Sat, 31 Oct 2026 12:59:18 +0000

A confirmation step is only worth something if nobody but the human can produce the "yes". That sounds obvious, and it's easy to get wrong once the "yes" travels over a protocol.

I built a small refund desk as an MCP server on ASP.NET Core with the official C# SDK (ModelContextProtocol 2.3.0). The issue_refund tool doesn't trust the model to confirm anything. It pauses and asks the person through MCP elicitation: a form with a checkbox, a reason, and for amounts over 100 EUR a field where you type the amount back. Since the 2026-07-28 spec this works on stateless servers too, through Multi Round-Trip Requests (MRTR).

Then I switched sides and tried to fake that "yes". These are the six attacks I ran, what happened, and what the server does now. The code is cut down to the shape, and the cut parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. The complete, working, tested version of this MCP refund desk is inside, with full source and an in-depth PDF guide. Join Tech Skill Builder

First, the flow I was attacking

On a stateless server the tool can't wait for an answer. It ends the call with input_required, a form to show, and an opaque requestState. The client shows the form, then calls the same tool again with the same arguments, the answers in inputResponses, and requestState echoed back. That second call can land on any instance.

In C# a tool asks by throwing. The shape of my tool:

[McpServerTool(Name = "issue_refund", Destructive = true, Idempotent = false)]
public async Task<CallToolResult> IssueRefund(McpServer server, RequestContext<CallToolRequestParams> context,
    ClaimsPrincipal? user, string orderId, decimal amount, CancellationToken cancellationToken)
{
    var ix = Begin(context, server, user);   // reads and verifies requestState on a retry (attacks 1 and 2)
    // ... order checks, the refusal for clients that can't show forms, building the form (omitted)

    if (ix.IsFirstCall)
        throw ix.Ask("confirm", new FormInput(form));   // becomes input_required + a sealed requestState

    var outcome = ix.Read("confirm", form);            // validated answer (attacks 3 to 5)
    // ... declined / cancelled / re-ask, then execute exactly once
    // (full implementation in the complete project)
}

Notice that both halves of the "yes" come from the client: the answers and the state. That's where every attack below aims.

Attack 1: Edit the state, keep the approval

What I did: approved a 25.00 EUR refund, then sent the retry with the same requestState but amount: 64.90 in the arguments.

What happened at first: my first spike kept plain JSON in requestState, like most samples do. The tool read the confirmation and applied it to the new amount. The MRTR spec says servers MUST treat requestState as attacker-controlled input, and this is why.

What stops it now: the state is sealed with ASP.NET Core Data Protection (authenticated encryption) and bound to the exact call it belongs to:

public sealed record RequestStateEnvelope
{
    public required string InteractionId { get; init; }
    public required string Tool { get; init; }
    public required string ArgumentsDigest { get; init; }  // SHA-256 over the canonical arguments
    public required string Subject { get; init; }          // the user who started the call
    public required int Round { get; init; }
    public required DateTimeOffset ExpiresAt { get; init; }
    // ... version, per-round nonce, form fingerprints, carried answers
    // (JSON names and the full record in the complete project)
}

The digest is computed over sorted keys with normalized numbers, so 25.00 and 25 match but 64.90 doesn't. The retry now fails with -32602: requestState does not match these arguments before any answer is read. Flipping one character of the sealed text gets requestState failed verification, and a state older than ten minutes gets requestState expired.

Attack 2: Replay someone else's approval

What I did: took Alice's valid, accepted state and sent it as Bob.

What stops it: the Subject binding. On every retry the server unseals and checks all the bindings at once:

var check = sealer.Unseal(requestState, tool, digest, subject);
if (!check.IsValid)
    throw new McpProtocolException(RejectionMessage(check.Status), McpErrorCode.InvalidParams);

Bob gets requestState was issued to a different user. A related trick, sending inputResponses with no state at all, is refused too, because nothing proves which question those answers belong to.

One operational note: every instance that might receive a retry needs the same Data Protection key ring and application name. Otherwise a perfectly honest retry fails verification on the other box.

Attack 3: Answer the form like a raw JSON client

Real MCP clients render the form nicely. An attacker doesn't need a real client. I sent:

"action": "ACCEPT" in capitals
accept with confirm: false
accept with an extra amount: 9999 field inside the form content

What I learned: the SDK's ElicitResult.IsAccepted is case-insensitive, so "ACCEPT" passes it. Don't use it as a consent check.

What stops it: an ElicitResponseValidator that checks the answer against the same FormSpec that produced the schema:

only lowercase accept, decline and cancel count as actions; anything else is treated as cancel
required fields, types, lengths, ranges and enum values are checked on the server
fields the server didn't ask for are ignored and reported, never bound
an accepted form with confirm: false is not consent, so the tool asks again with a hint

Because form and validator share one spec, they can't drift apart when someone adds a field.

Attack 4: Click Accept on an empty form

This one needed no hostile client at all, which makes it the scariest.

What I did: gave the confirm checkbox default: true (it looked friendly), then clicked Accept without touching anything.

What happened: the SDK client fills schema defaults into an accepted response for fields the user left empty. That's useful for a "close reason" that defaults to completed. On a consent checkbox it turns an empty click into consent on the wire.

What stops it: consent fields are required and have no default, and a linter checks every form the server can produce when the app starts:

FieldSpec.Boolean("confirm", "Issue this refund", required: true, consentBearing: true)

// at startup: lint every form, throw if any finding is an error
// (the 13 rules are in the complete project)

The demo run of the linter on a deliberately bad form:

lint: EL002 Error [confirm] Consent-bearing field has a default. The SDK client fills defaults into an accepted response, so an empty 'accept' would read as consent.
lint: EL011 Error [confirm] Consent-bearing field must be required.
lint: EL001 Error [cardPin] Looks like a secret or credential. Form mode MUST NOT collect these; use URL mode.

Attack 5: Approve something that no longer exists

What I did: opened the form ("120.00 EUR still refundable"), refunded 10 EUR as a colleague in another session, then accepted the original form.

What stops it: when the answer comes back, the server rebuilds the form from current data and compares its fingerprint with the one sealed in the state. If they differ, the user agreed to a form that's out of date, so the tool asks again and says "the form changed since it was shown".

For bigger refunds the typed-back amount adds one more barrier. Ticking a box and typing "150" are different acts, and a wrong number gets the form back. The server also stops after 4 rounds with a normal tool result, so the assistant has something to explain instead of an exception.

Attack 6: Get a secret into the conversation

Changing a payout account needs an IBAN. The tempting design is a form field called iban. The elicitation spec says form mode MUST NOT ask for passwords, API keys, tokens or payment credentials, and the linter above flags fields like that (EL001).

So change_payout_account uses URL mode. The tool asks the client to open a page on my server, the client shows the full host and asks before opening it, and the retry carries accept with no content. The link has a random reference and no personal data, and the page checks that whoever opens it is the user who started the tool call. When Bob opened Alice's link he got a 403. In the demo, a recorder on the MCP connection captured the whole flow, and none of it contained the IBAN.

Two SDK details: the server doesn't check the mode you send against what the client declared, and a client with a handler registered will receive URL requests it never declared. So the server checks capabilities before asking, and a form-only client gets a plain "needs a client that supports URL-mode elicitation" instead of a form fallback.

The attack I'm not answering here

All six are about forging or bending the "yes". There's one more that doesn't need forgery: the honest double submit. Alice clicks Accept, the proxy times out, her client retries with the same valid state, and the two requests land on different instances a few milliseconds apart. A sealed, bound, unexpired state is still not a single-use state. Making one approval move money exactly once across stateless instances, including after a crash halfway through the payment call, is a chapter of its own in the PDF that comes with the project.

A red-team checklist for your own confirmation tool

[ ] requestState is sealed, not plain JSON or base64
[ ] It's bound to the tool, the canonical arguments, the user and an expiry
[ ] Answers with no state are rejected
[ ] Actions are compared exactly; IsAccepted is not your consent check
[ ] Unknown fields are ignored, never bound
[ ] Consent fields are required and have no default, enforced by a startup lint
[ ] The form is rebuilt and compared before the answer is used
[ ] Secrets go through URL mode with a same-user check, never a form
[ ] Clients that can't show forms get a refusal for destructive tools, not a silent fallback

What I tested

The project has 285 passing tests (236 unit, 49 WebApplicationFactory integration tests) and needs no API key. A 10-scene CLI demo runs every attack above against a real Kestrel host with a raw JSON-RPC client, plus the two-instance scene. The SDK behaviors I mention (case-insensitive IsAccepted, default filling, URL requests reaching clients that didn't declare URL mode) came from spikes against 2.3.0 and are pinned as tests. What I haven't done is run it against every MCP client on the market, so test yours against the checklist.

Get the complete project

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. This project is already inside: the full .NET 10 solution with the sealed and bound requestState, the form spec, validator and 13-rule linter, five MCP tools including the two-round callback and the URL-mode payout page, the fallbacks for older clients, the client-side elicitation gate, the minimal API, the demo and all 285 tests, plus a PDF guide that goes much deeper than this post and answers the single-use question in full, with code. You also get the other complete, tested .NET + AI projects in the membership, with new ones added regularly.

Join Tech Skill Builder for $5/month

Which of these six would your current confirmation step let through?

The Shadow Model Issued a Refund: 7 Mistakes That Make LLM Model Upgrades in .NET Riskier Than They Look

MICHAEL-MAURICE — Fri, 30 Oct 2026 12:56:08 +0000

"Let's shadow the new model first, then canary it." Everyone agrees with that sentence in planning. It sounds like the careful option, and it is, as long as the shadow can't do anything and the canary is the same set of users on every server.

I built a model-upgrade pipeline for a .NET 10 support assistant on Microsoft.Extensions.AI 10.11.0. The assistant has three tools: get_order, issue_refund and escalate_to_human. Two of them move money or create work for people. That's on purpose, because a shadow setup that's harmless for a chatbot can be dangerous for an agent.

Here are seven mistakes I made, or nearly made, on the way. The code is trimmed to the shape, and the trimmed parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. The complete, working, tested version of this shadow and canary project is inside, with full source and an in-depth PDF guide. Join Tech Skill Builder

Mistake 1: Thinking you're upgrading a model id

The pull request says "switch to the new model". It usually also changes the system prompt "while we're at it", and maybe the temperature. Any one of those can change behavior. If your metrics only know the model id, you can't tell which change caused what, and two different prompts on the same model look like one release.

Fix: release the three together and give the combination a fingerprint:

public sealed record ModelRelease(string Name, string ModelId, PromptVersion Prompt,
    float? Temperature = null, int? MaxOutputTokens = null)
{
    public string Fingerprint => Hashing.Short(/* model id + prompt hash + options, culture-invariant (full version in the complete project) */);
}

In the project, a ReleaseChatClient (a plain DelegatingChatClient) pins a provider client to one release, so nothing in the app can quietly swap the prompt. The prompt registry is append-only: change a released prompt and you have a new release with a new fingerprint.

Mistake 2: Mirroring the whole request

This is the one in the title. The obvious shadow design sends each request through a second pipeline and compares the final answers. With tools, that second pipeline runs its own tool calls. In my demo, the "shadow" candidate rounded a refund up, and the order book ended with two refunds: 20.50 EUR from the live model and 21.00 EUR from the shadow. The shadow wasn't watching. It acted.

Fix: put the shadow under FunctionInvokingChatClient, so it compares one model turn at a time, and give the candidate the tools as declarations only:

public static ChatOptions DeclarationsOnly(ChatOptions? options)
{
    var o = options?.Clone() ?? new ChatOptions();
    // replace every AIFunction in o.Tools with f.AsDeclarationOnly(): same name and schema, not invocable
    // (full version in the complete project)
    return o;
}

The candidate decides with the same information, and its tool calls come back as FunctionCallContent that nothing executes. As a belt-and-braces check, the shadow runner asks the pipeline for GetService<FunctionInvokingChatClient>() and refuses to start if it finds one.

A nice side effect: comparing per turn gives you a precise, cheap signal. issue_refund {"amount":20.5} against issue_refund {"amount":21} doesn't need a judge to be flagged.

Mistake 3: Letting the shadow job hold references

The shadow runs later, on a background worker. If the job keeps references to the request's objects, it compares against something that has changed in the meantime.

Three ways this bit me:

Middleware that isn't under function invocation receives the caller's own message list. The app appends to it, so by the time the worker ran, the "input" had 3 messages instead of 1.
ChatMessage.Clone() is shallow. The clone and the original share one Contents list.
The request's cancellation token is cancelled when the request ends, which is exactly when shadow work starts.

Fix: snapshot on the request thread, with new messages and copied content lists, and give the runner its own timeout (through TimeProvider, so tests run on fake time) that's linked only to host shutdown.

Mistake 4: Trusting the channel to count what it dropped

The shadow must never slow down a real request, so jobs go into a bounded channel and are dropped when it's full. Fine. Then I counted the drops with the return value of TryWrite.

With BoundedChannelFullMode.DropWrite, TryWrite returns true for items it drops. In the demo, five writes into a channel of capacity two all returned true, and three of the jobs were gone.

Fix: count in the itemDropped callback you pass to Channel.CreateBounded, which is the only honest signal:

_channel = Channel.CreateBounded<ShadowJob>(
    new BoundedChannelOptions(capacity) { FullMode = BoundedChannelFullMode.DropWrite },
    dropped => { /* count it, and remember which job it was (omitted) */ });

Why it matters beyond ops: a queue that drops under load drops at peak hours, so your shadow sample quietly turns into a sample of quiet hours. The project's shadow gate holds when drops exceed a tenth of the enqueued jobs.

Mistake 5: Gating on "agreement"

The first gate I wrote said: promote if the candidate agrees with the current model often enough. On one simulated day, the shadow compared 898 turns and agreement was 58.4%. Was that bad?

Mostly it was style. The new prompt asked for a warmer tone, and "Good news! Your order is shipped..." scores low against "Order shipped." A terse model that gets dates wrong could score higher. Agreement measures voice as much as quality.

Fix: gate on mechanical red flags, each with its denominator, instead of on overall similarity:

the candidate refused where the current model answered (2.6% that day; my limit is 1%)
a different tool or different arguments on tool turns (13.0%; limit 2%)
text-versus-tool decision flips, candidate failures and timeouts, latency, and the drop rate

That first candidate held on refusals and tool divergence. And a shadow gate never rolls back on its own, because no user is exposed yet. It holds and waits for a person.

Mistake 6: Bucketing users with `GetHashCode()`

Once the shadow is clean, real users get the candidate. Each user must land on the same side on every request, every pod and every restart. Math.Abs(userId.GetHashCode()) % 100 looks fine and isn't: string hashing in .NET is randomized per process, so your 1% is a different 1% on every instance.

Fix: a stable hash with a per-rollout salt:

public static int Of(string salt, string subject)
{
    // SHA-256 over salt + separator + subject, first 8 bytes as an unsigned number,
    // modulo 10,000 buckets (full version in the complete project)
}

public static bool InCanary(string salt, string subject, int canaryBasisPoints) =>
    canaryBasisPoints > 0 && Of(salt, subject) < Math.Min(canaryBasisPoints, Buckets);

The salt keeps the same unlucky users from testing every model you ever ship. The "less than" makes the ramp monotonic, so going from 5% to 25% only adds users. Requests without a user stay on the current model during the canary.

Mistake 7: Fallbacks that hide failures, and gates that can't say "not sure"

When the candidate throws, retry the turn on the current model, so users on the canary get a slower answer instead of an error. Good. But if the retry also hides the failure from your metrics, you've built a slower way to promote a broken model. In the demo, a candidate that failed every third call caused 32 failed turns in 200 requests and zero user-visible failures, and the gates still saw all 32. A hard stop (at least 5 failures at a 20% rate or more) rolled it back immediately.

The second half of this mistake is a gate with only two answers. With small samples, "0 violations in 400 turns" doesn't prove much. The project's rate checks use a Wilson interval and have three outcomes: clearly worse (roll back), clearly fine (pass), or not conclusive yet (hold). At a half-point margin, 400 clean turns still leave the upper bound at 0.95%; you need about 800. At 1% of traffic that can take days, which tells you how short a 1% step is allowed to be.

Not every failed gate should roll back, either. Harm (failures, contract violations, p95 latency, negative feedback) rolls back automatically. A correct but slow candidate at 50% was rolled back on a p95 of 1,971 ms against 575 ms. Cost only holds for a person, because a more expensive model can be the right call.

A pre-flight list for your next model upgrade

[ ] Model id, prompt and options ship together under one fingerprint
[ ] The shadow compares single turns and can't execute tools
[ ] Shadow inputs are deep-copied on the request thread
[ ] Dropped shadow jobs are counted from the drop callback
[ ] Gates use refusals, tool divergence and flips, not raw agreement
[ ] Canary buckets come from a salted stable hash, not GetHashCode()
[ ] Fallbacks protect users but never hide failures from the gates
[ ] Every rate gate can answer "not conclusive yet"

What I tested, and what I didn't

The project has 206 passing tests (193 unit, 13 WebApplicationFactory integration tests), and none needs an API key. An offline support model has switchable bad habits (rounds refunds, refuses legal questions, fails every third call, runs slow), so each scenario above is a test, and a 10-scene CLI demo runs it all on fake time. The library behaviors I mention (the shallow Clone(), the shared message list, TryWrite under DropWrite, randomized string hashes) were checked with spikes against 10.11.0 and .NET 10, and are pinned as tests.

What I didn't do: run a rollout against real providers with real users. The traffic and every number in this post come from simulated days, so your thresholds will need tuning on your own traffic.

Get the complete project

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. This project is already inside: the full .NET 10 solution with releases and the prompt registry, the shadow pipeline that never acts, the response comparer, the sticky canary router with fallback, the Wilson-bounded gates, the rollout controller with its kill switch, the offline models, a minimal API and the 206 tests, plus a PDF guide that goes much deeper than this post, including how to decide when thousands of shadow disagreements are safe enough to promote. You also get the other complete, tested .NET + AI projects in the membership, with new ones added regularly.

Join Tech Skill Builder for $5/month

Which of these seven is hiding in your current upgrade plan?

Review Your LLM Tool Like a Public Endpoint: 8 Questions to Ask Before You Merge an AIFunction in .NET 10

MICHAEL-MAURICE — Fri, 30 Oct 2026 12:54:51 +0000

If a teammate opened a pull request that added a public HTTP endpoint, you'd ask questions. What happens with bad input? What does the caller see on error? Who is the caller, and how do we know? What happens when someone renames a field?

Now look at the last pull request that added an LLM tool. In .NET 10 it's often a method with a [Description] on it and one call to AIFunctionFactory.Create. It probably got approved in two minutes, because there was barely anything to read.

That's the trap. A tool is an endpoint. The caller is a model that writes its own arguments, and it will send you strings where you wanted numbers, parameters that don't exist and times in formats you never mentioned. So here are the eight questions I now ask in review for every tool, based on a room-booking assistant I built on Microsoft.Extensions.AI 10.11.0. The code below is trimmed to the shape. The trimmed parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. The complete, working, tested version of this tool-contract project is inside, with full source and an in-depth PDF guide. Join Tech Skill Builder

Question 1: Who chose the tool's name?

If the answer is "the compiler", send it back. AIFunctionFactory.Create on a lambda without a Name gets a generated name like RunAsync_1_0, and that's what the model is shown. The model will call it. It just has no idea what it does.

Method names aren't much better. People rename methods freely, and the tool name is part of the wire contract. In my project the name lives in an attribute, separate from the method:

[Tool("book_room", Effect = ToolEffect.Writes)]
[Description("Book a room for the current user. Use a roomId returned by find_rooms. Fails if the slot was taken meanwhile.")]
public BookingConfirmation BookRoom(
    CallerContext caller,   // bound from the request, not the model (Question 6)
    [Description("Room id from find_rooms, for example R-102."), RegularExpression("^R-[0-9]{3}$")] string roomId,
    // date, start, durationMinutes, attendees: described and bounded the same way (omitted)
    [Description("Short meeting title shown on the room display."), StringLength(80, MinimumLength = 3)] string title)
{
    // full implementation in the complete project
}

Tool is my own attribute, not part of the library. It also records whether the tool writes anything, and that flag ends up in the contract snapshot (Question 8). OpenAI only accepts function names matching ^[a-zA-Z0-9_-]{1,64}$, so check that too.

Question 2: What happens when an argument breaks the schema?

This is the question that surprised me most. The factory reads your DataAnnotations and puts them in the schema: [Range(15, 240)] becomes minimum and maximum, [RegularExpression] becomes pattern. Lovely. Then I called the raw function with durationMinutes: 300, and the method ran. The attributes describe the schema. Nothing checks them when the tool is invoked.

"We use OpenAI strict mode" is not an answer either. Strict mode guarantees the shape (right keys, right types, no extras), but the OpenAI adapter moves keywords like minimum, maximum and pattern into the description text to fit the supported schema subset. Your bound reaches the model as a sentence.

So the review question becomes: where in our code is the schema enforced? In my project, every factory-created function is wrapped in a DelegatingAIFunction that validates against the same schema the model was shown, before anything runs:

public sealed class ContractEnforcingFunction(AIFunction inner, /* validator, options, audit... */)
    : DelegatingAIFunction(inner)
{
    protected override async ValueTask<object?> InvokeCoreAsync(AIFunctionArguments arguments, CancellationToken ct)
    {
        // 1. validate `arguments` against JsonSchema (types, ranges, patterns, formats, unknown keys)
        // 2. on problems: return a structured error and do NOT call the method
        // 3. otherwise: await base.InvokeCoreAsync(...) and wrap the result
        // (full implementation in the complete project)
    }
}

The model still sees exactly the schema the factory generated. The wrapper just makes it true.

Question 3: What happens with an argument that doesn't exist?

With the raw factory function: nothing. Unknown keys are silently ignored. A model that sends duration instead of durationMinutes on a parameter with a default gets the default. A model that sends floor: 3 gets rooms on every floor and never learns there's no floor parameter.

For a public API you'd return a 400 listing the unknown field. Do the same here. My validator rejects unknown arguments and, when there's an obvious near-match, includes a suggestion ("suggestion": "durationMinutes"). Also note that argument names are case-sensitive in the binder, so DurationMinutes is "unknown" too unless you decide otherwise.

Question 4: Which near-misses do we fix, and which do we refuse?

Rejecting everything that isn't perfect costs a round trip, and round trips cost latency and tokens. Accepting everything means guessing. You want a written policy, not whatever the serializer happens to do. Mine is roughly:

"6" for an integer: accept as 6, and tell the model in a note.
"projector" for the enum value Projector: accept with a note. It can only mean one thing.
9:30 for 09:30: accept with a note.
9:30am, "six", integer enum values: refuse and say what format is expected.

The line is ambiguity. "Probably 09:30" is how a meeting ends up at 21:30. The notes go back with the successful result, and in practice the model switches to the canonical form on its next call. There's also a strict policy that refuses every coercion, handy in tests.

Question 5: What does the model read when the tool fails?

Throw an exception from a tool, and with the default IncludeDetailedErrors = false, FunctionInvokingChatClient gives the model exactly this:

Error: Function failed.

That default is right, because exception messages leak internals. But the model now knows nothing about which of its arguments was wrong, so it guesses. Turning detailed errors on mostly tells it how your binder works.

The review question is: are errors results? In my project, validation and business-rule failures come back as a structured envelope the model reads like any other output:

{"ok": false, "error": {"code": "invalid_arguments",
  "message": "2 arguments need fixing; nothing was executed.",
  "retryable": true, "problems": ["...one entry per argument, with path, code and expected..."]}}

"Nothing was executed" is there on purpose. For a write tool, the model needs to know whether retrying will book a second room. Unexpected exceptions still stay in your logs; the model gets an error id, not a stack trace.

Question 6: Can the model decide who the user is?

If the tool has a userId parameter, the answer is yes, and that's a finding. Every argument the model writes is something the prompt can influence.

AIFunctionFactoryOptions.ConfigureParameterBinding lets you take a parameter out of the schema and bind it yourself:

ConfigureParameterBinding = p => p.ParameterType == typeof(CallerContext)
    ? new AIFunctionFactoryOptions.ParameterBindingOptions
      {
          ExcludeFromSchema = true,
          BindParameter = (_, args) => /* read CallerContext from args.Context, or fail closed */,
      }
    : default,

The caller comes from the authenticated request and is copied into AIFunctionArguments.Context by a custom FunctionInvoker. A model that adds "userId": "admin" gets unknown_argument, because the contract doesn't have that parameter. No signed-in user means unauthorized, not a booking that belongs to nobody.

Question 7: How many times is the model allowed to be wrong?

Structured errors bring a new failure mode: a model that reads the error, apologizes and sends the same bad arguments again. FunctionInvokingChatClient has MaximumIterationsPerRequest and MaximumConsecutiveErrorsPerRequest, but a structured error isn't an exception, so the second limit never fires.

So each tool gets an invalid-argument budget per request (two, by default). On the last allowed failure the error says "retryable": false and tells the model to ask the user instead. If it calls the tool anyway, the custom invoker ends the loop:

ficc.FunctionInvoker = async (ctx, ct) =>
{
    // copy the caller into ctx.Arguments.Context (omitted)
    var result = await ctx.Function.InvokeAsync(ctx.Arguments, ct);
    if (/* this request has used up a tool's budget */) ctx.Terminate = true;
    return result;
};

The project's offline test model has a quirk that ignores error hints on purpose, and a test checks that it's stopped after two calls.

Question 8: What does this tool cost, and who notices when it changes?

Tool definitions are prompt text, sent and billed on every request that carries them. Two cheap CI checks answer this:

A linter. Mine has 16 rules: valid names, no compiler-generated names, every tool and parameter described, no untyped object parameters, no pairs of booleans that allow nonsense states, descriptions that aren't essays. On a deliberately sloppy tool class it reports 38 issues. The real tools: zero.
A size budget. The four real tools come to 2,787 characters, about 700 tokens by a chars/4 estimate. The useful number is the change when someone adds a tool with a three-paragraph description.

And then the part most teams skip: the schema is generated from method signatures, so renaming a parameter changes your API and the compiler doesn't care. A snapshot test of every advertised tool catches the change. What it should demand before anyone regenerates the snapshot, when old conversations still contain the old names, is the hard part, and it's a whole chapter of the guide.

The checklist version

Paste this into your PR template:

[ ] Tool name is explicit, stable and matches ^[a-zA-Z0-9_-]{1,64}$
[ ] Ranges, patterns and formats are enforced in our code, not only in the schema
[ ] Unknown arguments are rejected, with a suggestion when there's a near-match
[ ] There's a written coercion policy; anything ambiguous is refused
[ ] Failures come back as structured results that say whether anything executed
[ ] Identity comes from the request, never from a model-written argument
[ ] Each tool has an invalid-call budget, and the loop actually stops
[ ] Lint, size budget and schema snapshot run in CI

What I tested, and what I didn't

The project has 201 passing tests (190 unit, 11 WebApplicationFactory integration tests), and none of them needs an API key. A deterministic stand-in model with switchable bad habits (truncated names, string numbers, lowercase enums, 12-hour times, invented user ids, ignoring hints) makes every recovery path above a test. The library behaviors I describe (unenforced annotations, dropped unknown keys, "Function failed.", lambda names) were checked against Microsoft.Extensions.AI 10.11.0 and are pinned as tests, so a package update that changes one turns the build red.

What I didn't do in the tests: call a real model. You can flip one setting to run the same pipeline against OpenAI, but the numbers in this post come from the offline runs.

Get the complete project

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. This project is already inside: the full .NET 10 solution with the contract wrapper and validator, the coercion policy, caller binding, the retry budget, the linter, size budget and snapshot tools, the offline quirky model, a minimal API and the 201 tests, plus a PDF guide that goes much deeper than this post, including how to rename a tool without breaking the conversations already in flight. You also get the other complete, tested .NET + AI projects in the membership, with new ones added regularly.

Join Tech Skill Builder for $5/month

Which of these eight questions would your newest tool fail?

Stripe Will Send It Again: 7 Deliveries to Replay Against Your .NET Webhook Before Launch

MICHAEL-MAURICE — Thu, 29 Oct 2026 12:02:19 +0000

Most Stripe webhook endpoints get tested exactly once. You run stripe listen, trigger a checkout, see a 200, and move on.

That test proves the easy part. The hard part is everything Stripe promises in its docs: events arrive at least once, in no guaranteed order, and anything that doesn't get a 2xx is retried (in live mode, for up to three days). Your endpoint will meet all of that in production. It's much cheaper to meet it in a test first.

So instead of a build walkthrough, here's a replay list: seven deliveries I throw at a .NET 10 webhook endpoint before I trust it, what should happen for each, and how I check it. The code is trimmed to the shape. The trimmed parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. You get complete, working, tested .NET + AI projects with full source code and PDF guides. Join Tech Skill Builder

Need payments and subscriptions in your .NET 10 app? Stripe Integration for .NET 10 is $20 on Gumroad. More about it at the end.

The setup in one picture

POST /webhooks/stripe
  verify Stripe-Signature on the raw bytes   -> bad: 400
  parse the event; type we don't handle      -> 200 "ignored"
  insert into an inbox keyed by event id     -> 200 "queued" or 200 "duplicate"
                                                (database down: 503)
background worker: claim one row with a lease -> run the handler -> done / retry later / dead

The endpoint never runs business logic. It stores and answers. Keep that in mind, because most of the replays below are really testing that split.

Delivery 1: The plain retry

Replay: send the same event twice. Stripe signs every attempt again, so the second copy has a new timestamp and a new signature but the same event id.

Expected: both get 200. The second says duplicate, and the inbox has one row.

Watch the status code. It's tempting to answer a duplicate with 409. Don't: any non-2xx tells Stripe to try again, so you'd get retries of an event you already have.

Delivery 2: Fifty copies at the same moment

Replay: fire the same event 50 times in parallel.

Expected: exactly one queued, 49 duplicate, and one fulfillment.

This is the replay that kills "check if it exists, then insert". Two requests both check, both find nothing, both insert. The fix is to let the database decide, with a primary key on the event id and a single statement:

INSERT INTO webhook_inbox (event_id, type, payload, received_at)
VALUES ($id, $type, $payload, $now)
ON CONFLICT (event_id) DO NOTHING;
-- 1 row affected: first time. 0 rows: duplicate. (full column list in the complete project)

When I removed the primary key and the ON CONFLICT on purpose, four tests failed, including this one. That's how I know the test can actually catch the bug.

Delivery 3: Two different events for the same payment

Replay: two events with different ids that describe the same Checkout Session.

Expected: one fulfillment.

Stripe's docs mention that it sometimes sends two separate Event objects for one change. Your event-id inbox treats them as two events, correctly. So the inbox can't be your only line of defence. The handler also deduplicates on the business key, here the Checkout Session id, with its own unique constraint. There's another reason you need this: if the worker crashes after fulfilling but before marking the row done, the lease expires and the same event runs again.

Delivery 4: "Updated" arrives after "deleted"

Replay: customer.subscription.deleted, then a late customer.subscription.updated with status: "active".

Expected: the subscription stays canceled.

Stripe doesn't guarantee order, and its docs warn against sorting by created (one-second resolution). A naive upsert brings the subscription back to life. My handler never overwrites a terminal state:

-- inside the upsert's DO UPDATE:
WHERE subscriptions.status NOT IN ('canceled', 'incomplete_expired');

There's a second, optional defence: treat the event as a "something changed" signal and re-read the current subscription from Stripe. In my project that's an ISubscriptionSource interface, faked in the tests. I didn't wire it to the real Stripe API.

Delivery 5: A completed checkout that isn't paid

Replay: checkout.session.completed with payment_status: "unpaid", then checkout.session.async_payment_succeeded.

Expected: nothing is fulfilled on the first event; the order ships on the second.

"Completed" means the customer finished the checkout form, not that the money arrived. With delayed methods like bank debits, the payment lands later. The handler checks payment_status (paid or no_payment_required) and returns early otherwise:

if (paymentStatus is not ("paid" or "no_payment_required"))
{
    // log it and wait for checkout.session.async_payment_succeeded
    return;
}
// insert the fulfillment, unique on checkout_session_id (omitted)

Delivery 6: A body that was touched, and a secret mid-roll

Replay A: take a validly signed event, re-format the JSON (same data, different whitespace), and send it.

Expected: 400. The signature covers the exact bytes, so verify the raw body, never something you deserialized and serialized again.

Replay B: sign with the old secret while you're rolling to a new one. Stripe keeps the old secret alive for up to 24 hours and sends one v1 per active secret.

Expected: 200. My verifier tries every v1 entry against every configured secret, which is why I wrote it myself instead of using Stripe.net's EventUtility.ConstructEvent (that takes one secret). The tests use Stripe.net as an oracle: seven headers, including stale, future, wrong-secret and "bad v1 before a good one", go through both Stripe.net's check and mine, and they agree on all seven.

foreach (var secret in options.Value.SigningSecrets)
{
    // HMAC-SHA256 over "{t}." + raw body, keyed with the UTF-8 bytes of the whole whsec_ string
    // compare to every v1 with CryptographicOperations.FixedTimeEquals (full verifier omitted)
}
// then: |now - t| must be within 300 seconds, in both directions

Delivery 7: Your side is broken

Replay A: the inbox write throws (database down).

Expected: 503. This is the one case where you want Stripe to retry, because the next attempt can succeed.

Replay B: the event is stored fine, but the handler throws (say, the ERP times out).

Expected: Stripe already got its 200. The worker retries, with backoff (10 s, doubling, capped at an hour), and after 8 attempts parks the row as dead for a human. Stripe never hears about your ERP.

The status code table

Situation	Answer	Will Stripe retry?
Stored for the first time	200 `queued`	no
Already stored	200 `duplicate`	no
A type you don't handle	200 `ignored`	no
Bad, missing or stale signature; not an event	400	yes (fine: fix the secret and the retries recover)
Body over your size limit	413	yes
Inbox write failed	503	yes, on purpose

The rule behind it: choose each code by asking "would a retry help?"

What I tested, and what I didn't

The demo project has 52 passing xUnit tests, covering every replay above, plus a smoke run against the real host and worker. Every signature was made locally, with Stripe.net's helper and with Python's hmac.

What I didn't verify: a real Stripe account or the Stripe CLI, Stripe's real retry timing, a real ISubscriptionSource, or several app instances on one database. The inbox is SQLite, so it's single-host. For more instances, move the same unique key and claim query to Postgres or SQL Server.

Want the full Stripe integration?

Stripe Integration for .NET 10 is $20, one-time, from Elite Solutions. It's a Clean Architecture + DDD solution (Domain, Application, Infrastructure, Api) with CQRS and MediatR, EF Core and Swagger, with Stripe.net wrapped in a StripeService. It covers customers, products and prices, Payment Intents, Checkout Sessions, refunds, subscriptions, invoices and webhooks with signature verification and deduplication by Stripe event ID, plus unit tests. To be clear: the replay demo from this post (the SQLite inbox, the worker and the 52 tests) is a separate project and is not part of the kit.

And if you learn best from complete code you can run, Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. You get complete, working, tested .NET + AI projects with full source code and step-by-step PDF guides, and new ones are added regularly.

Join Tech Skill Builder for $5/month

Which of these seven would your endpoint fail today?

Half Price Until You Pay Twice: 6 Ways an OpenAI Batch Job in .NET Quietly Costs You More

MICHAEL-MAURICE — Thu, 29 Oct 2026 12:01:25 +0000

The pitch for the OpenAI Batch API is simple. You have a pile of work nobody needs answered in two seconds, say 40,000 rows to classify overnight. You put the requests in a JSONL file, upload it, and the provider finishes within 24 hours at half the price of the normal API.

The discount is real. What eats it is the code around the batch. A batch job lives for hours, and anything that lives for hours meets crashes, retries and deadlines. Each of those can quietly turn "half price" into "full price, twice", or into results that are silently missing.

Here are six mistakes I made or nearly made while building a batch pipeline in .NET 10 (official OpenAI 2.14.0 package, SQLite for state). The steps are general. The code is trimmed to the shape, and the trimmed parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. The complete, working, tested version of this batch project is inside, with full source and an in-depth PDF guide. Join Tech Skill Builder

Mistake 1: Creating the batch again after a crash

This is the expensive one. Your worker uploads the file, calls "create batch", and dies before it saves the batch id. On restart, your database says this shard was never sent, so you send it again. Now two batches run the same requests, and you pay for both.

The fix doesn't need extra infrastructure. Batches accept metadata, so tag each one with your own shard id when you create it. On restart, before re-sending a shard that has no batch id, list the recent batches and look for that tag:

var metadata = new Dictionary<string, string>
{
    ["job_id"] = job.Id,
    ["shard_id"] = shard.Id,
};
// create the batch with this metadata, then save the batch id (full flow in the complete project)

// on restart, for a shard with no saved batch id:
var match = recent.FirstOrDefault(b =>
    b.Metadata.TryGetValue("shard_id", out var sid) && sid == shard.Id);
// match found: adopt it. none found: send it. Never both.

The other half of the rule: save your state before every provider call (planned, then uploaded, then created), so a restart always knows how far it got.

Mistake 2: Retrying everything that failed

A batch comes back with failures, and the easy move is "put the failures in the next batch". Some of those failures will fail again no matter how often you send them. A 400 for a malformed request or a model refusal gets the same answer the second time, and you pay for it again.

So sort the failures before you retry anything:

Retry: 408, 409, 429 and 5xx, batch_expired, lines that never came back, and output that parsed but broke your schema.
Retry with more room: finish_reason: length. The next attempt doubles max_completion_tokens, up to a cap.
Don't retry: other 4xx, refusals and content-filter stops.

And give every item an attempt budget (three in my project). When it runs out, the item goes to a dead-letter state with its last reason instead of looping forever.

One more thing on cost: when an attempt is truncated, you still paid for its tokens. My store adds each attempt's tokens to the item rather than replacing them, so the cost report shows what you actually paid.

Mistake 3: Looping over the output file

The docs say it plainly: output lines may not come back in input order. That part most people catch, and they join on custom_id. The subtler bug is which side you loop over.

If you loop over the output file, items with no line at all simply never show up. Cancelled batches, expired batches and the occasional lost line all look like that. The job reports "done" and a few hundred rows were never processed.

Loop over what you sent instead, and look each one up:

foreach (var (itemId, attempt) in shard.Members)
{
    if (decisions.ContainsKey(itemId)) continue;   // a line came back for it
    // no line at all: retry, with a reason like "missing_after_cancel" or "missing_after_expiry"
    // ... (reason mapping and the rest of the reconciler are in the complete project)
}

Also read the second file. Failed requests go to a separate error file, and that's where expired requests show up.

Mistake 4: Reusing the same custom_id on a retry

Item r-042 fails in batch one and goes into batch two. If its custom_id is still r-042, a late line from batch one is indistinguishable from the fresh answer, and it can overwrite a newer result.

Put the attempt number in the id. My format is {jobId}:{itemId}:a{attempt}, so the retry is ...:r-042:a2. Any line carrying a1 after that is stale, and the reconciler ignores it. Lines from another job are ignored the same way, and a second line for the same id counts as a duplicate.

The database side gets the same treatment: an update only lands if the item is still at that attempt and still waiting for a result, so a late line can't overwrite newer state.

Mistake 5: Letting the JSON encoder inflate your file

Each input file has limits: 50,000 requests and 200 MB. The default System.Text.Json encoder escapes every non-ASCII character as \uXXXX. For English text, that changes nothing. For Arabic it hurts. In my measurement, one short Arabic ticket went from 116 bytes to 324.

On long non-English rows, the byte limit starts to bind before the 50,000-request limit, so the same job needs more files and more batches. One option fixes it:

var options = new JsonWriterOptions { Encoder = JavaScriptEncoder.UnsafeRelaxedJsonEscaping };
// write custom_id, method, url, body with a Utf8JsonWriter using these options (builder omitted)

Despite the scary name, it still escapes control characters, so a newline inside a row can't split a JSONL line. I have a test for exactly that, because it's the first thing I'd worry about.

While you're there, validate the file locally before uploading: unique custom_ids, one model per file, url equal to the batch endpoint, no stream: true, and within the limits. A mistake caught locally costs nothing.

Mistake 6: Panicking at the deadline

The Batch API promises 24 hours. Your report is due at 08:00. At 07:40 the batch is still running and half the rows are done.

The panic move is "cancel it and run everything through the normal API". That pays full price for the rows the batch already finished, and a cancelled batch still produces output for what it completed, which you're billed for too.

The better question is when to stop trusting the batch, and how to finish only what's left without paying twice. My project answers that with a deadline planner. How it decides, and what it costs, is in the complete project and its PDF guide, not here.

The pre-flight checklist

[ ] State saved before every provider call
[ ] Every batch tagged with your shard id; crash recovery adopts before it re-sends
[ ] Failures classified: retry, retry with more tokens, or fail for good
[ ] Attempt budget and a dead-letter state
[ ] Tokens added across attempts, not replaced
[ ] Reconcile over what you sent, using both the output file and the error file
[ ] Attempt number inside custom_id; stale and foreign lines ignored
[ ] Relaxed JSON encoder, and a local file validator
[ ] A deadline plan that doesn't throw away finished work

What I tested, and what I didn't

The project has 162 passing tests (146 unit, 16 integration), with no API key needed. An offline simulator covers the documented batch lifecycle, including failed, expired and cancelled batches, and a test crashes the process right after "create batch" to prove recovery adopts the existing batch instead of creating a second one.

What I didn't do: run it against the live Batch API. The OpenAI adapter was tested against an in-process server that speaks the documented Files and Batches format, not against OpenAI itself. Also note that BatchClient is marked experimental (OPENAI001) in the 2.14.0 SDK, so expect it to change.

Get the complete project

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. This batch project is already inside: the full .NET 10 solution with the 162 tests, the crash recovery, the reconciler, the deadline planner, a minimal API with idempotent job creation, and a PDF guide that goes much deeper than this post. You also get the other complete, tested .NET + AI projects in the membership, with new ones added regularly.

Join Tech Skill Builder for $5/month

Which of these six would hit your batch job first?

Your Telegram AI Assistant Can Email Anyone as You: 6 Checks to Run Before the Model Does

MICHAEL-MAURICE — Wed, 28 Oct 2026 17:46:36 +0000

Picture the assistant: you hold the mic in Telegram, say "find 30 minutes with Sara on Thursday and email her the options", and a minute later the email is in her inbox. n8n makes that easy. A Telegram Trigger, a Whisper transcription, an AI Agent with Gmail and Calendar tools, and you're most of the way there.

Notice what you just built, though: a bot that can send email as you, triggered by anyone who can reach a webhook. The model is the least interesting risk here. The interesting ones happen before the model runs.

I built this with n8n plus a small ASP.NET Core API (.NET 10) that makes the decisions I don't want a model to make. The general steps below are the ones that matter. Code is trimmed to the shape.

Tech Skill Builder is $5/month for a very limited time (normally $10) — grab it now before it goes back to $10. Complete, tested .NET + AI projects with full source and PDF guides. 👉 Join Tech Skill Builder

The shape

Telegram Trigger -> guard API (allowed?) -> voice or text?
   voice -> download -> Whisper -> prompt
   text  ----------------------> prompt
prompt -> AI Agent (tools: contacts, calendar, free slots, email) -> reply on Telegram

The first node after the trigger asks the API one question: may this update run at all? Everything that costs money or has side effects sits behind the answer. Here are six checks, in roughly the order a message meets them. The first four live in that guard; the last two protect the tools the agent calls.

Check 1: Is this chat one of mine?

The Telegram Trigger already checks the secret token, and in my local run the webhook was registered with it. That proves the request came from Telegram. It does not prove you wrote the message. Anyone on Telegram can message your bot.

So: an allowlist of chat IDs, and everyone else is ignored without a reply. A reply tells a stranger the bot exists and is listening.

Check 2: Have I seen this update before?

Telegram retries a delivery when it doesn't get a fast 2xx (a restart, a slow node, a proxy hiccup). A retried "email Sara the report" is two emails.

Remember each update_id for a window and let only the first one through. Two retries can land at the same moment, so a "check, then add" pair isn't enough. It needs one atomic operation:

// one atomic step, not "if (!seen.Contains(id)) seen.Add(id)"
if (!_seen.TryAdd(updateId, now))
{
    // already there: duplicate inside the window, or expired and re-added (omitted)
}

The test I trust here fires the same update many times in parallel and expects exactly one to pass.

Check 3: Is it stale?

After an hour of downtime you don't want ten queued commands to fire at once. n8n's trigger can drop pending updates when you re-publish (in my local run it registered the webhook with drop_pending_updates), but I still compare the message date with the clock and refuse anything older than ten minutes (a setting).

Check 4: How big is this voice note?

A 20-minute voice note isn't a command, it's a transcription bill. Read the duration from the update and refuse before downloading anything. In my setup the limit is 120 seconds, and the bot answers "please keep it under 2 minutes".

public GuardDecision Evaluate(TelegramUpdate update)
{
    // ... bot check, allowlist, duplicate, age (the checks above, in this order)
    if (m.Voice is { } voice && voice.Duration > o.MaxVoiceSeconds)
        return new(false, "voice_too_long", m.Chat.Id);
    // ... allowed: return kind, text or voice file id
}

The order matters: cheap checks first, anything that costs money last.

Check 5: Which "Omar"?

Ask a model to email Omar and it may produce omar@company.com with total confidence. Make the contact lookup a tool, and make its answer one of three: found, ambiguous, not_found. The system prompt then says: never guess an address; on anything but found, ask which person and stop.

In my run, a voice note saying "book 30 minutes with Omar" ended with the bot asking which of the two Omars I meant, and nothing was sent.

Check 6: What time did the model mean?

Models send "2026-10-29T10:00:00", no offset. Deserialize that into a DateTimeOffset and you get the server's offset. I checked: on a box with TZ=UTC it parsed as 10:00+00:00, three hours off for an assistant living in Cairo.

So the API takes the time as a string, and treats an offset-less value as the assistant's own zone:

local = DateTime.SpecifyKind(local, DateTimeKind.Unspecified);
// handle a time that doesn't exist (spring-forward gap): omitted
var utc = TimeZoneInfo.ConvertTimeToUtc(local, zone);

The same goes for working hours: convert them to UTC per day, not once from the first day's offset. A clock change between two days is where the shortcut breaks. When I swapped the per-day conversion for the shortcut, exactly two tests failed, which is how I know the tests cover it.

What I checked, and what I didn't

The API has 43 passing xUnit tests. I also ran the whole n8n workflow locally (n8n 2.43.8) against the real API, with a fake Telegram, OpenAI and Google. It covered a text request, a Telegram retry (ignored), a voice note about an ambiguous contact, a voice note that was too long, a stranger's chat (ignored) and a missing or wrong secret token (HTTP 403).

What I didn't check: real Telegram, real Whisper, real Gmail and Calendar (no credentials, so those nodes were only validated against n8n's node schemas), and how well a real model picks tools. The dedup store is in memory, so with more than one instance you'd move it to Redis or a database key.

The checklist

[ ] Allowlist of chat IDs; strangers get silence
[ ] Atomic dedup on update_id
[ ] Stale messages refused
[ ] Voice duration capped before download
[ ] Contact lookup is a tool with found / ambiguous / not_found
[ ] Offset-less times get your zone, not the server's
[ ] Cheap checks first, paid steps last

Want to skip the n8n part?

If you'd rather start from a finished Telegram assistant than wire the nodes yourself, the n8n Workflow Vault is $29 one-time: the AI Phone-Calling Personal Assistant for Telegram (voice and text, Whisper, Google Sheets contacts, phone, email and calendar agents), the Ultimate n8n Workflow Pack with 2,000+ templates, the multi-agent orchestration workflow and the UGC ad video generator. You bring your own API keys. The guard API from this post is a separate demo and is not part of the Vault.

And if you learn best from complete code you can run, Tech Skill Builder is $5/month for a very limited time (normally $10) — grab it now before it goes back to $10. You get complete, working, tested .NET + AI projects with full source code and step-by-step PDF guides, and new ones are added regularly. 👉 Join Tech Skill Builder

Which of these six would your bot fail first?

Deleted, Emptied, Half-Written: 6 Files a Nightly RAG Ingestion Job Gets Wrong in .NET 10

MICHAEL-MAURICE — Tue, 27 Oct 2026 11:59:48 +0000

Most RAG ingestion demos end after the first run: a folder of Markdown goes in, the chat answers a question, done. But a knowledge base changes all the time. Pages get deleted, trimmed, moved and rewritten, and an ingestion job that runs every night has to keep the vector index in step with all of that.

I built a small help-center ingestion service on .NET 10 with Microsoft.Extensions.DataIngestion (10.11.0-preview.1.26513.7, still a preview package) and the in-memory vector store. The pipeline itself (read, chunk, enrich, embed, write) was the quick part. Most of my time went into six ordinary things that can happen to a file. For each one there's a simple question: what should the index hold the next morning?

Code below is trimmed to the shape; omitted parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. The complete ingestion service from this post, with an in-depth PDF guide, is inside Tech Skill Builder.

The one idea behind all six

Don't treat ingestion as "process this folder". Treat it as a sync between two things: the files on disk, and a ledger that records what the index is supposed to hold for each document (content hash, generation number, chunk count, status). Every run compares the two and decides one action per document:

public enum PlannedAction
{
    Add, Update, Reindex, Repair, Retry, Skip, Quarantined, Delete,
}
// IngestionPlanner.Plan(sources, ledger, fingerprint, liveChunkCounts): a pure function,
// full implementation in the complete project

Because the planner does no I/O, every branch below has a plain unit test.

File 1: the page you deleted

Somebody removes welcome.md. The pipeline only processes files that exist, so it never hears about this one. Its chunks stay in the index, and the assistant keeps quoting a page that's gone.

Rule: anything in the ledger but no longer on disk is a Delete. The job first stops serving it, then deletes its chunks and the ledger row. In the demo that run makes zero model calls and zero embedding calls, and removes the page's one chunk.

Test: Deleted_file_loses_its_chunks_and_ledger_row.

File 2: the page cut down to its title

Someone trims invoices.md to a single heading. It now produces zero chunks.

This one surprised me. The library's writer has an incremental mode (IncrementalIngestion, on by default) that replaces a document's old chunks, but it does that when the first new chunk arrives. With no new chunks, nothing triggers it, and the old three chunks stay searchable. A characterization test in the project pins that behaviour: Builtin_incremental_mode_keeps_old_chunks_when_the_new_version_is_empty.

Rule: I turn the built-in mode off and replace by generation myself. A successful run with zero chunks still deletes the old generation, and the document is marked Empty instead of quietly serving its previous version.

Test: Emptied_file_loses_its_chunks.

File 3: the page that didn't change, in a folder that moved

Same files, new deploy path. By default the reader uses FileInfo.FullName as the document id, so /srv/release-41/billing/refunds.md and /srv/release-42/billing/refunds.md are two different documents, and the index ends up with two copies of everything.

Rule: the id is the path relative to the source root, with forward slashes (billing/refunds.md). A small reader decorator makes sure the pipeline uses that id too:

public sealed class StableIdReader(IngestionDocumentReader inner, string root) : IngestionDocumentReader
{
    // both ReadAsync overrides map FileInfo.FullName to the root-relative id
    // full implementation in the complete project
}

While you're there, hash the content after normalizing line endings and stripping a BOM. Otherwise a Windows build agent with core.autocrlf makes every file look edited.

Test: Moving_the_source_folder_does_not_duplicate_anything (second run: 6 of 6 unchanged, same chunk count).

File 4: the page that grew too big

Someone pastes a huge log into a page and it goes over the size limit (2,000,000 bytes by default in my settings). A scanner that just leaves it out of its list has a nasty side effect: next to the ledger, a missing file looks exactly like a deleted one.

Rule: oversized files are reported as skipped, and the job refuses to delete them from the index. The index keeps serving the last good version until someone fixes the file.

Test: Too_large_file_is_skipped_but_not_deleted.

File 5: the page whose embedding call died halfway

close-account.md changes, and the embedding provider returns a 503 after two chunks of the new version are already written. Now the index holds half of the new version next to the complete old one.

Rule: every write is a new generation (a small chunk processor stamps the generation number on each chunk). The commit order is: save the ledger, publish the new generation, then delete the old ones. On failure, delete whatever part of the new generation landed and leave the ledger pointing at the old one:

if (!result.Succeeded)
{
    var partial = await _index.DeleteAsync(id, g => g == generation, ct);
    // record the failure (hash, count, error) in the ledger: in the complete project
}

The demo's run report says it in one line: removed 2 partial chunk(s); previous version still served.

Test: Mid_write_failure_removes_partial_chunks_and_keeps_serving_the_old_version.

File 6: the page that fails every single night

If the failure is in the content itself (or the provider keeps rejecting it), a naive job retries every night forever, paying for enrichment calls each time.

Rule: count failures per content hash. After 3 failures of the same content (MaxAttempts), the document is Quarantined and skipped with zero model calls. Any edit to the file releases it, and reverting the file to the version that's still live clears the failure.

Tests: Repeated_failures_quarantine_until_the_file_changes, Editing_a_quarantined_file_releases_it.

The cheap part: nothing changed

All six rules rely on the planner, and the planner gives you the best one for free. In the offline demo, the first run over six files made 18 model calls and embedded 17 texts. The second run, with no changes, made 0 model calls and embedded 0 texts, in 4 ms. Unchanged files never reach the pipeline.

Checklist

[ ] Ids relative to the source root, never absolute paths
[ ] Content hashes that ignore line endings and a BOM
[ ] Deleted files are purged, with a test
[ ] Emptied files are purged, with a test (the built-in incremental mode won't do it)
[ ] Oversized files are skipped and reported, never treated as deleted
[ ] A failed write removes its partial chunks and keeps the old version live
[ ] Repeated failures of the same content are quarantined
[ ] Unchanged files cost zero model calls

There's one problem I haven't covered here: while a document is being replaced, a search can briefly see chunks from two versions. How search avoids that, with one live generation per document, is covered in the project and the PDF.

Get the complete project

The snippets above are the outline. The complete .NET 10 solution, Production RAG Ingestion for .NET 10, is in Tech Skill Builder: the scanner and pure planner, generation-based commits, quarantine, store-loss repair, an orphan sweep after crashes, redaction before chunking, an enrichment contract on top of the library's best-effort enrichers, live-generation search, an ASP.NET Core minimal API and a 15-scene CLI demo. It has 131 offline tests (118 unit, 13 integration), including 10 characterization tests that pin the preview library's behaviour, plus an in-depth PDF guide. No API key needed to run it.

Tech Skill Builder gives you complete, working, tested .NET projects with full source code and step-by-step PDF guides, with new ones added regularly. Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. Join Tech Skill Builder

Which of these six has your ingestion job already got wrong?

One Clarifying Question, One Line of C#: 5 Interview Bugs I Planted on Purpose

MICHAEL-MAURICE — Tue, 27 Oct 2026 11:58:54 +0000

Most advice about coding interviews says "ask clarifying questions". It rarely says why the interviewer cares. My answer: every good clarifying question ends up as one specific line of code. If you can point at that line while you talk, you've shown you write code from requirements, not from memory.

To check that idea, I took a small practice project (four classic problems in C# on .NET 10, each with a brute force and an optimized version, 34 xUnit v3 tests) and broke one line at a time. Each line is the answer to a question you should ask out loud. Then I counted how many tests failed.

Four of the five bugs were caught. One got through all 34 tests, and that one taught me the most.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. Complete, working, tested .NET projects with full source code and step-by-step PDF guides: Tech Skill Builder.

If you're preparing for .NET backend interviews in general, my .NET Backend Interview Masterclass (2026 Edition) goes much wider than algorithms. More on it at the end.

How the experiment works

Every problem has one extra test besides the hand-picked cases: run the brute force and the optimized version on 500 random small inputs with a fixed seed, and require the same answer. The brute force is slow, but it's easy to trust, so it works as the reference for the fast one.

For each bug below I changed one line, ran dotnet test, wrote down what failed, and reverted the change.

Bug 1: "Can I use the same element twice?"

Two Sum, the hash map version. The answer "no" is enforced by the order of two lines: look up the complement first, insert the current value second.

for (var j = 0; j < nums.Count; j++)
{
    long complement = (long)target - nums[j];
    if (seen.TryGetValue(complement, out var i)) return (i, j); // 1. look up
    seen.TryAdd(nums[j], j);                                    // 2. then insert
}
// null check, doc comment and brute force: in the complete project

What I broke: I moved the insert above the lookup.

What noticed: 3 tests. [3] with target 6 now "finds" a pair (index 0 with itself), [3, 3] returns (0, 0) instead of two different indices, and the random comparison failed too.

Say it out loud: "I check before I insert, so an element can't pair with itself."

Bug 2: "How big can the numbers get?" (the one that got through)

The same method does its math in long, because int.MaxValue + 1 silently wraps around in an int. The project even has a test row for it: [int.MaxValue, 1, int.MinValue] with target -1.

What I broke: I switched both the brute force and the optimized version to plain int arithmetic.

What noticed: nothing. 34 of 34 passed.

The reason is a little embarrassing. In that test row, the correct pair (int.MaxValue + int.MinValue = -1) doesn't overflow at all, so int math still finds it. The row looks like overflow coverage, but it can't fail. And the random test couldn't help: it uses small values, and I had broken both versions in the same way, so they still agreed.

The case that does catch it is one where wrapping creates a false match:

{ [int.MaxValue, 1], int.MinValue, false }, // int math: MaxValue + 1 wraps to MinValue

I added that row in a scratch copy, and the int version failed it straight away (the real long version passes). It isn't in the project yet.

Say it out loud: "If the values can be near int.MaxValue, I'll add in long. And my test for that needs a case where wrapping would produce a wrong yes, not just one where it happens to work."

Bug 3: "What if the repeat is already outside my window?"

Longest substring without repeating characters, sliding window version. This one isn't a question for the interviewer. It's a question you ask yourself while you trace an example.

if (lastIndex.TryGetValue(s[right], out var previous))
    left = Math.Max(left, previous + 1); // the left edge never moves backwards
// rest of the loop (update lastIndex, track best): in the complete project

What I broke: left = previous + 1; without the Math.Max.

What noticed: 2 tests: the "abba" row (the broken version returns 3, the right answer is 2) and the random comparison.

Say it out loud: "Let me trace abba. At the last a, the previous a is at index 0, which is already outside the window, so left must stay where it is."

Bug 4: "Must the subarray be non-empty?"

Maximum subarray (Kadane). If the answer is "yes, take at least one element", then an all-negative array returns its largest single value, not 0. That decision lives in the seed:

long endingHere = nums[0], best = nums[0]; // not 0
// the loop and the empty-input guard: in the complete project

What I broke: seeded both with 0.

What noticed: 2 tests: [-3, -1, -2] (expected -1) and the random comparison.

Say it out loud: "You said non-empty, so I seed with the first element. Otherwise an all-negative input would return 0, which isn't the sum of any subarray."

Bug 5: "If one meeting ends at 10 and the next starts at 10, can they share a room?"

Meeting rooms, sort-and-sweep version. If the end time is exclusive, a room is freed when the next start is at or after the earliest end. That's one character:

while (e < ends.Length && ends[e] <= start) { e++; rooms--; }
// sorting starts and ends, and counting rooms: in the complete project

What I broke: <= to <.

What noticed: 2 tests: back-to-back meetings 9-10, 10-11, 11-12 (expected 1 room) and the random comparison.

Say it out loud: "That <= is your answer from earlier. Back-to-back meetings can share a room."

What the scoreboard says

Bug	Clarifying question	Tests that failed
Insert before lookup	Same element twice?	3
`int` instead of `long`	How big are the values?	0
No `Math.Max` on `left`	Repeat outside the window?	2
Kadane seeded with 0	Non-empty subarray?	2
`<` instead of `<=`	Exclusive end time?	2

Two things I took from it:

The random brute-force comparison was in every catch. It failed on its own for all four bugs that were caught. In an interview you won't have time to write it, but one sentence earns credit: "With more time, I'd check this against the brute force on random small inputs."
A test named after an edge case isn't proof that the edge case is covered. The overflow row looked right and couldn't fail. Breaking the line on purpose is the quickest way to find out.

Your practice checklist

[ ] Ask the question, then write the answer as a comment or a test case
[ ] Point at the line that implements each answer
[ ] Trace one awkward input by hand (abba, all negative, back-to-back)
[ ] For overflow, test a case where wrapping gives a false yes
[ ] Mention the brute-force cross-check, even if you can't write it

Want to go further?

The .NET Backend Interview Masterclass (2026 Edition) is a 142-page guide ($20) with 200+ C# questions with full code, a system design playbook with 7 high-frequency scenarios (webhooks, payments, feed pagination and more) and a 6-box thinking script, EF Core and SQL performance, the ASP.NET Core runtime, security and reliability, a 14-day prep plan, a STAR+L behavioral bank and 8 printable cheat sheets. To be upfront: the small kata project from this post is my own and isn't part of the guide.

And if you learn best from complete code you can run, Tech Skill Builder gives you complete, working, tested .NET projects with full source code and step-by-step PDF guides, with new ones added regularly. Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. Join Tech Skill Builder

Which clarifying question has saved you in a real interview?

Your First AI Feature in .NET 10 in 15 Minutes

MICHAEL-MAURICE — Tue, 27 Oct 2026 09:56:12 +0000

You don't need a vector database, an agent framework or a weekend to ship your first AI feature in .NET. You need one interface, IChatClient, and about fifteen minutes.

In this post we'll build a small but real feature: a support ticket triage endpoint. You POST a customer email, and you get back a category, a priority and a one-line summary as a typed C# object. Then we'll stream a reply draft and make the model swappable with one line.

📄 Want the full version of every snippet here? Grab the free .NET AI Starter Cheat Sheet. Enter your email and get it free: 8 pages of copy-paste C# covering the whole .NET AI stack, tool calling, structured output, RAG, MCP and a production checklist.

🔥 Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. Complete, tested .NET + AI projects with full source and step-by-step PDF guides: Join Tech Skill Builder

The plan (and the clock)

Minutes	Step
0 to 2	Create the project and add two packages
2 to 5	Register `IChatClient` once, in DI
5 to 9	Typed triage with structured output
9 to 12	Stream a reply draft
12 to 15	Guardrails, and swapping the model

The code below shows the shape of each step. Some parts are trimmed and marked as such.

Minute 0 to 2: project and packages

dotnet new webapi -n TicketTriage --use-minimal-apis
cd TicketTriage
dotnet add package Microsoft.Extensions.AI
dotnet add package Microsoft.Extensions.AI.OpenAI
dotnet user-secrets init
dotnet user-secrets set "OpenAI:Key" "<your-key>"

Microsoft.Extensions.AI gives you the abstractions (IChatClient, ChatMessage, ChatOptions) and the middleware. Microsoft.Extensions.AI.OpenAI is the adapter that turns the OpenAI SDK client into an IChatClient. Your app code will only ever see the interface.

Keep the key in user secrets (or environment variables in production). Never in appsettings.json, and never in Git.

Minute 2 to 5: one registration, used everywhere

The mistake I see most often in first AI features is new OpenAIClient(...) inside a controller. Register the client once and inject the interface instead:

using Microsoft.Extensions.AI;
using OpenAI;

builder.Services
    .AddChatClient(sp => new OpenAIClient(builder.Configuration["OpenAI:Key"])
        .GetChatClient("gpt-4o-mini")
        .AsIChatClient())
    .UseLogging();
    // more middleware (telemetry, caching, tool calls): see the cheat sheet

That builder is a pipeline. Every call goes through the middleware you add, in order, before it reaches the model. Logging is enough for today.

Minute 5 to 9: typed triage, not string parsing

Here's the part that makes it feel like a real feature. Don't ask the model for "JSON please" and then fight JsonSerializer. Ask for a C# type:

public enum Priority { Low, Normal, High, Urgent }

public record Triage(string Category, Priority Priority, string Summary);
public record TicketRequest(string Body);

app.MapPost("/tickets/triage", async (IChatClient ai, TicketRequest req) =>
{
    ChatResponse<Triage> res = await ai.GetResponseAsync<Triage>(
    [
        new(ChatRole.System, "You triage support emails for an online shop. ..."),
        new(ChatRole.User, req.Body)
    ]);

    // ... validate res.Result before trusting it (step 5)
    return Results.Ok(res.Result);
});

GetResponseAsync<T> generates a JSON schema from your record, sends it with the request and deserializes the answer into Triage. Using an enum for Priority means the model can't invent a "Kinda urgent" level.

The system prompt matters more than the code here. Mine lists the allowed categories and says what counts as urgent. I've cut it short above because the wording is where most of the tuning goes.

Minute 9 to 12: stream the reply draft

A triage result is small, so waiting for it is fine. A reply draft is longer, and a spinner for six seconds feels broken. Stream it:

app.MapPost("/tickets/draft", (IChatClient ai, TicketRequest req) =>
    StreamDraft(ai, req));

static async IAsyncEnumerable<string> StreamDraft(IChatClient ai, TicketRequest req)
{
    await foreach (var update in ai.GetStreamingResponseAsync(/* system + user messages */))
        yield return update.Text;
}

Returning IAsyncEnumerable<string> from a minimal API endpoint sends the chunks as they arrive. The front end shows the text as the model writes it. Cancellation, retries and Server-Sent Events are the next layer up, and you can skip them for a first version.

Minute 12 to 15: guardrails and the one-line swap

Three things I'd add before anyone else uses this:

Cap the cost. Pass new ChatOptions { MaxOutputTokens = 300, Temperature = 0.1f } for triage. Low temperature for classification, a little higher for drafts.
Don't trust the result blindly. If Summary is empty or the category isn't in your list, fall back to "Needs a human". The model will be wrong sometimes, and your code should expect that.
Cap the input. Truncate the email body before sending it. A 40-page pasted log shouldn't cost you a dollar.

And the payoff for coding against the interface: switching to a local model for development is one registration change.

// dev: a local model through Ollama (OllamaSharp implements IChatClient)
builder.Services.AddChatClient(new OllamaApiClient(new Uri("http://localhost:11434"), "llama3.2"));

Your endpoints, prompts and records don't change at all.

What we skipped on purpose

To keep it to fifteen minutes I left out tool calling (letting the model look up the customer's order), RAG (answering from your own help-center docs), telemetry and evals. Those are the steps that turn a demo into something you'd put in front of customers, and each one has a few traps.

Get the full version, free

Every snippet in this post, completed, plus tool calling, RAG in six steps, an MCP server in C# and a production checklist, is in the free .NET AI Starter Cheat Sheet. Enter your email and get it free. 📄

When you're ready for complete projects instead of snippets, Tech Skill Builder gives you working, tested .NET + AI solutions with full source and step-by-step PDF guides. Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. Join Tech Skill Builder

What was the first AI feature you shipped in .NET, or the one you're planning? Tell me in the comments.

Parameterized Queries Can't Help Here: 6 SQLite Traps When an LLM Writes Your SQL

MICHAEL-MAURICE — Mon, 26 Oct 2026 12:02:16 +0000

The standard answer to SQL injection is "use parameterized queries". It's good advice, and it doesn't help at all once a language model writes the entire statement. There's no user value to bind. The query itself is the untrusted input.

I spent a week building the guard for an "ask your shop data" assistant on .NET 10 with SQLite. The big design decision came early: don't parse SQL in C#. SQLite already has a full parser for its own dialect, so the guard compiles each statement and asks the engine what it would do. The surprises came later, in the details. Here are six SQLite and Microsoft.Data.Sqlite behaviours that would each have let something through.

The project uses Microsoft.Data.Sqlite 10.0.13 (SQLite 3.53 via SQLitePCLRaw) and Microsoft.Extensions.AI 10.11.0 for the structured model output. Code below is trimmed to the shape; omitted parts are marked.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. The complete text-to-SQL guard from this post, with a step-by-step PDF, is inside Tech Skill Builder.

Trap 1: you read one row, and the DELETE still runs

I ran SELECT id FROM orders LIMIT 1; DELETE FROM orders through a plain SqliteCommand, read a single row, and let the using block dispose the reader. Afterwards the table had zero rows.

That's documented behaviour: Microsoft.Data.Sqlite supports batches, and disposing the reader executes any statements that haven't been consumed yet. So a guard that only looks at the first statement passes, and the second one runs anyway.

The fix is to compile the statement yourself with sqlite3_prepare_v2 and then compile the tail. If the tail produces a real statement handle, refuse:

var rc = raw.sqlite3_prepare_v2(db, sql, out sqlite3_stmt stmt, out string tail);
using (stmt)
{
    if (rc != raw.SQLITE_OK) { /* a SQL error, not a violation: eligible for repair */ }
    if (HasAnotherStatement(db, tail)) { /* refuse: multiple_statements */ }
    // read-only, EXPLAIN, bound parameters and result-column checks: in the complete project
}

Don't settle for "the tail isn't empty", by the way. Models love ending with ; -- done, and a comment-only tail compiles to an empty handle, which is fine.

Trap 2: "read-only" is narrower than it sounds

sqlite3_stmt_readonly looks like the perfect check. But per the SQLite docs, it reports true for BEGIN, ATTACH and DETACH, because they don't write to the database file. That's correct from SQLite's point of view, and it's not what you want for model output.

So I still use it, but it isn't the main lock. The main lock is the next one.

Trap 3: SQLITE_IGNORE turns a refusal into wrong data

sqlite3_set_authorizer registers a callback that SQLite calls while compiling: once per table/column read, per function, per statement type. That's the real allowlist. My callback allows SELECT and RECURSIVE, allows reads only of columns in the catalog, allows about 30 listed functions, and denies everything else:

internal PolicyViolation? Decide(int actionCode, string? p0, string? p1) => actionCode switch
{
    raw.SQLITE_SELECT or raw.SQLITE_RECURSIVE => null,
    raw.SQLITE_FUNCTION => DecideFunction(p1),       // allowlisted names only
    raw.SQLITE_READ     => DecideRead(p0 ?? "", p1 ?? ""), // catalog tables and columns only
    _ => new("statement_not_allowed", ActionName(actionCode)),
};
// DecideFunction, DecideRead and ActionName: full implementation in the complete project

The trap is the return value. For a column read, SQLITE_IGNORE makes SQLite return NULL instead of failing. Nothing errors, and that's exactly the problem: "show me customer emails" answers with a column of NULLs, and the user concludes you have no emails on file. I return SQLITE_DENY, so the statement fails to compile and the user gets an honest refusal.

Trap 4: count(*) reads a column with no name

Hiding a table from the catalog isn't enough if SELECT count(*) FROM payout_accounts still works. It tells an attacker how many rows exist.

The authorizer does fire for that query, just with an empty string as the column name (the SQLite docs describe exactly this). It's easy to write a rule that treats "no column" as "nothing to check". Mine allows the empty column only for catalog tables and denies it for any real table that isn't in the catalog. A test named Denies_hidden_tables_even_for_count_star keeps it that way.

Trap 5: pooled connections keep your hooks

Since version 6.0, Microsoft.Data.Sqlite pools connections by default. The authorizer and the progress handler (which I use for query deadlines) live on the native sqlite3 handle, not on your SqliteConnection object.

In a spike I installed a deny-all-reads authorizer, closed the connection, opened a new one with the same connection string, and ran a simple SELECT. It failed with "access to orders.id is prohibited". The hook had survived through the pool. With Pooling=False, the same second query worked.

Either direction is bad: unrelated code can inherit your guard, or your guarded path can get a handle without it. Every guarded connection in the project is unpooled and opened read-only, and both hooks are removed in a finally. There's a test for it, Hooks_do_not_leak_between_runs.

Trap 6: the repair loop becomes a search engine

Models get column names wrong, and feeding SQLite's error back ("no such column: category_name") usually fixes it on the next try. So a repair loop is worth having.

But only for honest mistakes. If you also send back "access to customers.email is prohibited", you've told the model what's off limits and asked it to try another way in. In my service, SQL errors get up to two repair rounds (MaxRepairAttempts = 2). Policy violations end the request as Refused immediately, the model never sees why, and timeouts aren't repaired either:

if (run.Kind == QueryRunKind.SqlError && calls < maxCalls)
{
    // add the draft and PromptBuilder.RepairMessage(run.Error) to the conversation, try again
}
// violations: Refused, codes only, no repair (full flow in the complete project)

The checklist

[ ] Compile the SQL and the tail; exactly one statement or refuse
[ ] Don't treat sqlite3_stmt_readonly as the main lock
[ ] An authorizer allowlist for tables, columns, functions and statement types
[ ] SQLITE_DENY, never SQLITE_IGNORE
[ ] Hidden tables denied even for count(*)
[ ] Unpooled, read-only connections, hooks removed in finally
[ ] A deadline (progress handler) plus row and cell caps
[ ] Repair SQL errors, never policy violations, with a hard limit

The project has 134 offline tests (121 unit, 13 integration with WebApplicationFactory) and a fake model that misbehaves on purpose: it writes DELETEs, stacks statements, goes after hidden columns and writes a recursive CTE that never ends.

All of this still assumes one shop per database. Put 40 shops in the same tables and a perfectly "allowed" SELECT SUM(total) FROM orders reads everyone's revenue. Where the tenant boundary should live is the hardest part, and I cover it in the project and the PDF.

Get the complete project

The snippets above are the outline. The complete .NET 10 solution is in Tech Skill Builder: the semantic catalog that drives both the prompt and the allowlist, the statement inspector, the authorizer, a per-tenant sandbox, deadlines and caps, the bounded repair loop, a privacy-aware audit trail, an ASP.NET Core minimal API, a 21-scene CLI demo and all 134 tests, plus an in-depth PDF guide. No API key needed to run it.

Which of these would your current text-to-SQL feature fall for?

DEV Community: MICHAEL-MAURICE

My Sale Ended at the Wrong Midnight: 6 Bugs in Time-Limited Discount Codes in .NET

Bug 1: "End of day" in the server's time zone

Bug 2: Nobody tested the boundary

Bug 3: Rounding in three different places

Bug 4: The subscription keeps the discount forever

Bug 5: Max-uses check that races

Bug 6: Validating the code only when it's typed

The short checklist

Want the full projects?

I Masked the User's Message and the Email Still Left: 7 Places PII Slips Out of a .NET 10 LLM Pipeline

Place 1: Round two of function calling

Place 2: Tool results, after JSON escaping

Place 3: Your logs

Place 4: The model's own answer

Place 5: Placeholders nobody issued

Place 6: Values the detectors refuse to mask

Place 7: The audit trail

What this is not

Pre-flight checklist for a PII shield

What I tested

Get the complete project

Faking a Yes: 6 Attacks I Ran Against the Human Confirmation in My .NET 10 MCP Server

First, the flow I was attacking

Attack 1: Edit the state, keep the approval

Attack 2: Replay someone else's approval

Attack 3: Answer the form like a raw JSON client

Attack 4: Click Accept on an empty form

Attack 5: Approve something that no longer exists

Attack 6: Get a secret into the conversation

The attack I'm not answering here

A red-team checklist for your own confirmation tool

What I tested

Get the complete project

The Shadow Model Issued a Refund: 7 Mistakes That Make LLM Model Upgrades in .NET Riskier Than They Look

Mistake 1: Thinking you're upgrading a model id

Mistake 2: Mirroring the whole request

Mistake 3: Letting the shadow job hold references

Mistake 4: Trusting the channel to count what it dropped

Mistake 5: Gating on "agreement"

Mistake 6: Bucketing users with GetHashCode()

Mistake 7: Fallbacks that hide failures, and gates that can't say "not sure"

A pre-flight list for your next model upgrade

What I tested, and what I didn't

Get the complete project

Review Your LLM Tool Like a Public Endpoint: 8 Questions to Ask Before You Merge an AIFunction in .NET 10

Question 1: Who chose the tool's name?

Question 2: What happens when an argument breaks the schema?

Question 3: What happens with an argument that doesn't exist?

Question 4: Which near-misses do we fix, and which do we refuse?

Question 5: What does the model read when the tool fails?

Question 6: Can the model decide who the user is?

Question 7: How many times is the model allowed to be wrong?

Question 8: What does this tool cost, and who notices when it changes?

The checklist version

What I tested, and what I didn't

Get the complete project

Stripe Will Send It Again: 7 Deliveries to Replay Against Your .NET Webhook Before Launch

The setup in one picture

Delivery 1: The plain retry

Delivery 2: Fifty copies at the same moment

Delivery 3: Two different events for the same payment

Delivery 4: "Updated" arrives after "deleted"

Delivery 5: A completed checkout that isn't paid

Delivery 6: A body that was touched, and a secret mid-roll

Delivery 7: Your side is broken

The status code table

What I tested, and what I didn't

Want the full Stripe integration?

Half Price Until You Pay Twice: 6 Ways an OpenAI Batch Job in .NET Quietly Costs You More

Mistake 1: Creating the batch again after a crash

Mistake 2: Retrying everything that failed

Mistake 3: Looping over the output file

Mistake 4: Reusing the same custom_id on a retry

Mistake 5: Letting the JSON encoder inflate your file

Mistake 6: Panicking at the deadline

The pre-flight checklist

What I tested, and what I didn't

Get the complete project

Your Telegram AI Assistant Can Email Anyone as You: 6 Checks to Run Before the Model Does

Mistake 6: Bucketing users with `GetHashCode()`