DEV Community: Prithwiraj Das

The Bugs Were Never in the New Code

Prithwiraj Das — Sun, 28 Jun 2026 05:00:21 +0000

When you add a feature to an old system, the new code is usually fine. The bugs come from the old code's assumptions, the ones nobody wrote down because back then they were just true.

I hit a small version of this recently. One feature, three bugs, all the same underlying thing. It wasn't until afterward that I realized I'd been running into this same pattern for years and had never written any of it down. The examples here are from a C# stack, but the shape is the same across the stacks I've worked in.

The setup

A multi-tenant platform. One screen had a long-standing way of doing something, gated behind some legacy config. We were adding a newer way to do the same thing, opt-in, for a subset of customers. So for a transition period there were two flows living side by side on the same screen.

This is a familiar shape if you've modernized anything live. You don't get to delete the old flow on day one. The old and the new have to coexist, and that coexistence is where the assumptions quietly pile up.

It shipped, and for most customers it worked. Then one slice of customers, the ones who had the new flow turned on and none of the old config, hit a blank screen on freshly created records. A refresh fixed it.

That last detail is the tell. When a refresh fixes it, the data is usually fine and the rendering path is where things went wrong. When I pulled the thread, it wasn't one bug. It was three, stacked on top of each other, and each one turned out to be the same mistake wearing different clothes.

Bug one: a sibling pretending to be a child

The new logic had been added inside the conditional that handled the old flow.

public ScreenData GetScreenData(Guid recordId)
{
    var legacyData = _legacyRepo.Fetch(recordId);
    var result = new ScreenData();

    if (legacyData != null)                       // gate for the OLD flow
    {
        result.Legacy = Populate(legacyData);

        if (_customer.HasNewFeature)              // NEW logic, nested inside
        {
            result.NewFeature = PopulateNewFeature(recordId);
        }
    }

    return result;
}

Customers who had both flows were fine, because the legacy data existed for them. Customers who had only the new flow failed the outer check, the whole block was skipped, and the new logic nested inside it never ran.

Here is the part I want to be honest about. I read this code. It did not announce itself. Sitting next to the code it lived beside, nesting it was the natural-looking thing to do, and nothing on the page says it's wrong. The only way to see the problem is to already know there's a customer config where that outer condition is false, and that fact isn't written anywhere in the code. The fix is to make the new logic a sibling instead of a child:

public ScreenData GetScreenData(Guid recordId)
{
    var legacyData = _legacyRepo.Fetch(recordId);
    var result = new ScreenData();

    if (legacyData != null)
    {
        result.Legacy = Populate(legacyData);
    }
    else
    {
        result.Context = FetchContextDirectly(recordId);   // new-only path still works
    }

    if (_customer.HasNewFeature)                  // SIBLING: runs in both cases
    {
        result.NewFeature = PopulateNewFeature(recordId);
    }

    return result;
}

Bug two: a heuristic that expired

The screen refreshed its content only when one specific field changed, because historically that field was the only thing the panel depended on.

Finding this one took a minute, because everything upstream looked correct. The API returned the right data. The debugger showed the right model. The values were all there, and the panel still sat empty until a manual refresh. That narrowed it to one place: something had stopped telling the panel it needed to redraw.

private void OnSave(IReadOnlyCollection<string> changedFields)
{
    if (changedFields.Contains(PrimaryField))     // the one thing it used to depend on
    {
        RefreshPanel();
    }
}

The new feature introduced a second thing the panel now depended on, and the refresh logic knew nothing about it. So in the exact case where the new dependency changed but the original field didn't, the panel never refreshed. The check was correct the day it was written. It stopped being correct the moment the data started depending on something else.

I didn't re-plumb this one. It was a small feature already moving through the release pipeline, and rewriting the refresh path the right way wasn't something I could fit into that window. So it got a targeted fix and a note for later. That's the real version of this work: the right fix and the shippable fix aren't always the same one, and the feature in the pipeline doesn't wait for the cleanup you'd rather do.

Bug three: context that fell off a boundary

This is the one that's actually interesting.

The old framework had a built-in way to embed one piece of rendered output inside another. The new framework dropped it, so somewhere along the line it had been rebuilt by hand to keep the old views working. The rebuild rendered the embedded piece by spinning up a fresh, isolated sub-request.

In a multi-tenant system, "isolated" is the whole problem. The tenant context, the thing that tells the system whose data it's allowed to read, lived in the ambient state of the outer request. The sub-request didn't inherit it.

// Outer request: tenant is present in ambient scope
public IActionResult Render(Guid recordId)
{
    var tenant = _ambient.Tenant;                 // "customer 42"
    var data = _service.GetData(recordId);        // correctly scoped to customer 42
    var model = BuildModel(data);                 // controller has the RIGHT data

    // ...the hand-rolled embed helper re-renders a fragment:
    return EmbedFragment(model);
}

private IActionResult EmbedFragment(Model model)
{
    using var sub = _requestFactory.CreateNew();  // fresh scope, NO ambient tenant
    var data = _service.GetData(model.RecordId);  // scoped to nothing -> empty
    model.Fragment = data;                        // empty overwrites the correct data
    return View(model);
}

So the right data was fetched, then thrown away and re-fetched in a context that no longer knew the tenant. The re-fetch came back empty and overwrote the good result with nothing. Blank screen.

The deeper thing underneath it: ambient context doesn't cross a boundary. The moment you open a sub-request, a thread, a background job, or a queue message, whatever was "just there" stops being there. That's the piece that came back on me later at a much bigger scale.

One mistake, three forms

It was only after the third one that I saw all three were the same shape. None of them were failures in the new feature. Each one came from something the old system had quietly depended on for years and never stated.

A branch nested too deep, a trigger scoped too narrow, a rebuild that lost its context. Underneath, the same thing: an assumption that was true in the old system and false in the new one, never written down because it never needed to be.

What AI did and didn't do

I planned this feature with AI in the loop, so it's worth being straight about where it helped and where it didn't.

My history with this work has three stages. For years I did it by reading code for days and holding the system in my head, and I still missed things, because nobody holds a whole system at once. Then AI became a faster lookup and a decent rubber duck. Now it's more than that: I hand it a scoped piece of discovery, get an analysis back, turn that into a plan, take the plan to the people who need to sign off on it, and execute. It doesn't replace the judgment. It shortens the distance from a question to a plan I can stand behind.

That's how this one went. AI helped me map the existing flow and draft the change. I wrote the transition plan and walked the team through it. The plan was sound, and we shipped it. It still missed all three seams.

The reason isn't "AI is a junior and I'm the senior who catches its mistakes." AI is good at the code that's there. None of these bugs were in the code that's there. They were in things written down nowhere: which customer configs exist, how people actually move through the screen, where the tenant context silently rides along. You can't read those in the new code, because they aren't in it.

There's a scoping piece too, and it has nothing to do with how smart the model is. When you hand a model a task, you hand it a boundary, and it works inside that boundary. The blast radius of the change doesn't respect the boundary. A change scoped to "the new feature's logic" came out in the rendering path, the refresh trigger, and the tenant plumbing, three places outside the frame I'd drawn. That's not the model failing the task. That's the scope not matching the system. And I draw the scope too narrow for the same reason it does: the parts that break are the parts nobody marked as connected. The blind spot was shared, and it came from two directions at once.

The same three mistakes, at backend scale

None of this is specific to web frameworks. It's what modernization does at any scale, and it gets more expensive the deeper down it goes. The same three mistakes show up when you break a monolith into services, and they show up in an order most write-ups skip.

Nobody starts at the database. You start at the easy edges. Logging goes first, because it's nearly standalone and pulling it out costs almost nothing. The database comes last, because the database is where these migrations stall. Logic is cheap to move; data isn't. So the monolith database keeps running as the source of truth for everything that hasn't moved, each new service comes up with its own store, and a warehouse on the side stays in step through change-data-capture over an event hub or Kafka.

The textbook says you finish by decommissioning the monolith and its database. In practice that step usually never comes. The old database stays underneath as load-bearing infrastructure nobody is funded to pull out. It's too entangled to be worth removing, so you leave it, the same way you leave a bug that's out of scope for the feature that's already shipping. The pattern is supposed to replace the monolith. Most of the time it just learns to live with it.

Every one of those moves is one of the three bugs, grown up. Routing capabilities around the monolith instead of through it is the same sibling-or-child question: does this run beside the old path, or inside it. The event-fed warehouse is the expired heuristic: it stays correct exactly as long as every real change emits an event, and the first write that slips through without one leaves the read store quietly wrong, with no error to announce it. And the cross-service context is the lost-boundary problem, which is the worst of the three. In the monolith, tenant and trace and transaction are all just present, because everything shares one scope. Add a service hop and none of it travels unless you carry it on purpose.

// Monolith: context is ambient, just there
public void Handle(Request request)
{
    Process(request);          // tenant, trace, transaction all implicitly available
}

// Distributed: the boundary strips it unless you pack it in explicitly
public async Task Publish(OrderEvent message)
{
    // forgot to attach TenantId / TraceId to the message...
    await _bus.Send(message);
}

public async Task Consume(OrderEvent message)
{
    var tenant = message.TenantId;   // null — whose data is this? nobody knows.
    // ...processing happens against the wrong (or no) tenant scope
}

My screen bug was a tenant ID that didn't survive a sub-request inside a single process. The same bug across services is a tenant ID that doesn't make it onto a published message, and it surfaces in a consumer far away that's now processing data without knowing whose it is. Same mistake, much bigger radius. It's the whole reason distributed tracing and explicit context propagation exist as a discipline: ambient context doesn't cross boundaries on its own.

There's a smaller one in the same family worth naming, because it bites early. When you finally do move logic out of a stored procedure and into application code, people expect the database load to drop. It usually climbs. The procedure did one round trip with a join:

-- one round trip, one result set
SELECT o.*, c.name, t.weight
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN tasks t     ON t.order_id = o.id
WHERE o.id = @id;

The "modernized" version moves the join into code and quietly turns one query into many:

var order = _repo.GetOrder(id);                        // query 1
var customer = _repo.GetCustomer(order.CustomerId);    // query 2
foreach (var task in order.Tasks)                      // lazy-loaded...
{
    task.Weight = _repo.GetWeight(task.Id);            // query 3, 4, 5, ... N
}

The logic moved and the data access multiplied. Moving logic out of the database doesn't move the data out of it. If you don't redesign the access along the way, you've built something slower and called it modern.

So the three things that broke one small screen are the three things that shape, and routinely break, a large migration: what runs beside the old path versus inside it, data that has to stay consistent across a gap that used to be a single transaction, and context that doesn't survive a boundary.

What I do differently now

I don't use AI less. Discovery is faster and the plans are better for it. What changed is where my attention goes.

The model handles the code that's there. The part that's mine is the code that isn't: the assumptions written down nowhere, the configs that only exist in production, the context that rides along until a boundary drops it. So I spend less time on the new code and more on a single question, what assumption am I about to break, and where is it written down. It almost never is written down anywhere, which is exactly why it's still the part that needs a person.

The feature was never where the risk lived. The risk lived in assumptions someone made years earlier and never expected to change. That's where I start looking now, not because the new code doesn't matter, but because the bugs were almost never in it.

Feature Flags Are Not a Free Lunch

Prithwiraj Das — Thu, 02 Apr 2026 04:06:29 +0000

Every article about trunk-based development eventually arrives at the same recommendation: use feature flags. Gate incomplete work behind a toggle. Merge to main freely. Turn features on when they are ready.

I have implemented this. And over the past few years, I have watched it create a category of technical debt that nobody warned me about.

This is not an argument against feature flags. They are a useful tool. But the advice to "just use feature flags" leaves out what happens six months later when nobody cleans them up.

The plan is always clean

You are building a new feature. It is not ready for all users yet. So you wrap it behind a feature flag. During development, the flag is off in production. Your code lives in main, safely dormant.

When the feature is ready, you turn the flag on. Once all users have adopted it and the old code path is no longer needed, you remove the flag.

Development, release, adoption, cleanup. Four steps.

In practice, step four almost never happens.

Why flags become permanent

The first time a feature flag sticks around longer than planned, it feels harmless.

Client A adopted the new feature. Client B did not want to move yet. The flag stays on for A and off for B. No big deal. We will clean it up next quarter.

But next quarter, a new feature gets built on top of the flag-on code path. Now removing the flag means untangling the new feature from the old toggle. The effort is not justified, so it gets pushed again.

Meanwhile, Client C onboards and gets a third configuration. The flag is no longer a temporary gate. It is load-bearing infrastructure that was never designed to be permanent.

I have worked on codebases where feature flags that were supposed to last a sprint were still active two years later. Not because anyone decided to keep them. Just because removing them required more effort than anyone could justify in a sprint cycle.

One flag doing too much

Feature flags start simple: on or off.

Over time, they absorb responsibilities they were never meant to carry.

In one project, a single feature flag controlled two completely unrelated things: the data source for a report and the visibility of certain columns in the UI. The flag was originally created for the data source migration. The column visibility logic was added later because it was "related enough" and creating a separate flag felt like overkill.

When the team needed to decouple those behaviors for different clients, it turned into a multi-sprint effort. The simple toggle had become a load-bearing wall in the application logic.

This pattern repeats. Flags accumulate side responsibilities because it is faster to add a condition to an existing flag than to create and manage a new one. Each addition makes the eventual cleanup harder.

The client matrix problem

Feature flags become genuinely dangerous when combined with client-specific targeting.

In a multi-tenant application, it is common to enable features per client. Client A gets the new engine. Client B stays on the old one. Client C gets the new engine but not the new reporting module. Each combination is a distinct application state.

Now multiply that across several flags. Flag A controls data source. Flag B controls UI behavior. Flag C controls a calculation engine. Different clients have different combinations. The number of possible states grows fast.

Nobody tests all of those combinations. The QA team tests the most common configurations. But an untested combination is a production incident waiting to happen.

I have spent hours debugging issues that turned out to be caused by an unexpected interaction between two flags that were never designed to work together. The code was correct for each flag individually. It just had not been tested in that particular combination.

Migrating flag platforms

Here is something that should set off alarm bells: if your team is migrating from one feature flag platform to another, the flag sprawl has already gotten out of hand.

I have been through one of these migrations. The stated goal was modernization and cost reduction. The unstated reason was that the old platform had accumulated so many stale, undocumented flags that nobody trusted it anymore.

What actually happened: every active flag had to be recreated in the new platform. Every client-specific targeting rule had to be rebuilt. Every code reference had to be updated. Tickets were created just to promote individual flags from dev to staging to production. The migration took multiple sprints and added zero user-facing value.

And the new platform? Within months, it started accumulating the same kind of sprawl. Because the problem was never the platform. It was the lack of lifecycle governance.

The naming problem

When multiple teams create feature flags independently, naming conventions diverge fast.

In one codebase, I saw flags named like team-feature-enable alongside flags named like project-component-updates. Different teams, different conventions. Some flags used feature names. Others used team abbreviations. There was no central registry and no way to look at a flag name and understand what it controlled without reading the code.

A new developer picking up a ticket that involved feature flags had to trace each flag through the codebase to understand what it did, which clients it applied to, and whether it was still active. That detective work added hours to what should have been straightforward tasks.

What I think about now

After living through flag chaos more than once, there are things I would set up before adopting feature flags at scale.

Every flag gets a creation date, an owner, and an expected removal date. If the flag is still active past its expected date, it shows up somewhere visible and someone is accountable for it.

One flag, one responsibility. If you are tempted to add a second behavior to an existing flag, create a new flag instead. The cost of managing an extra flag is far lower than untangling an overloaded one later.

A naming convention before the first flag exists. The format matters less than the consistency.

Dedicated time every quarter to audit active flags, remove stale ones, and consolidate duplicates. This never feels urgent, which is exactly why it needs to be scheduled.

And if you have client-specific targeting, maintain a test matrix of the most common flag combinations. At minimum, document which combinations exist in production and make sure QA covers them.

Feature flags are a useful tool. But without lifecycle discipline, they create the same kind of mess they were supposed to prevent. The chaos just moves to a different layer.

What Goes Wrong When You Switch Branching Strategies Mid-Flight

Prithwiraj Das — Wed, 01 Apr 2026 19:50:27 +0000

I have been part of at least four branching strategy migrations over a 12-year career.

GitFlow to trunk-based. Bitbucket to GitHub. Sprint branches to release branches and back again.

Every time, the decision to switch made sense on paper. Every time, the real problems showed up later, usually during the first production hotfix.

Trunk-based development is the right long-term model for most teams. I am not arguing against it. But I have seen enough transitions go sideways that I wanted to write down what I have noticed, in case it is useful to someone going through the same thing.

The switch usually happens fast

In most places I have worked, the decision to change branching strategies came from leadership during a broader initiative. A platform migration, a new CI/CD tool, a push to modernize.

The intent is always good. But the rollout tends to be uniform. Every repo switches at once, regardless of whether each team is ready for the new workflow.

The thing is, a branching strategy is not really an infrastructure decision. It is a team capability decision. It works when the team's release cadence, test coverage, and deployment setup are aligned with it.

When those things are not in place yet, the new model introduces problems that the old model, for all its flaws, did not have.

The test gap

Trunk-based development assumes main is always releasable. That is a strong assumption.

It only holds if automated tests run in the pipeline as a blocking gate.

In more than one team I have been part of, tests were encouraged but not enforced in CI. Code could land in main without passing automated validation.

In a branch-based model, that is survivable. Bad code sits in a feature or develop branch. You catch it before it reaches production.

In trunk-based, there is no buffer. Main is production. If the pipeline does not block on test failures, you are relying on code review alone to catch runtime bugs and regressions.

I have seen this pattern repeat across organizations. The branching model changes. The test infrastructure does not follow.

The pipeline is the enforcement mechanism. If it does not fail on failing tests, those tests are effectively optional.

The hotfix that could not ship

This is where it gets real.

A critical bug surfaces in production. The fix is reviewed and ready.

But main has other changes in it that are not production-ready. Unfinished features, untested integrations. Deploying the fix means deploying everything.

In theory, trunk-based prevents this because main should always be clean. In practice, that takes time to build: small commits, good CI, feature flags for incomplete work. During the transition period, main is rarely in that state.

I have been in a situation where a straightforward hotfix took over 24 hours to unblock. The pipeline was not set up to deploy from anything other than main. The development team, the engineering manager, and the DevOps team all had to coordinate to add hotfix branch support on the spot.

For teams working on business-critical applications, whether it is healthcare, logistics, or e-commerce, this is especially painful. Hotfixes are not rare events. Access control bugs, data display issues, calculation errors. These come up regularly and need to ship the same day.

A branching strategy that turns a one-line fix into a coordination exercise has a gap that needs addressing.

The pipeline is not always in your hands

Something that rarely comes up in branching strategy blog posts: in many organizations, developers do not control their own deployment pipelines.

The CI/CD setup is owned by a DevOps or platform team. Developers can push code, but they cannot change workflow triggers, deployment rules, or environment settings.

This is a reasonable separation of concerns. But it creates a coordination bottleneck during transitions.

When the team I was on needed hotfix deployments added to the pipeline, it was not something we could do ourselves. It required a request to DevOps, who had to evaluate the change across dozens of repositories. That is a fair concern on their end. But on the development side, there was a fix ready to go and no way to ship it.

Branch naming conventions added another layer. The pipeline required specific patterns like feature/TICKET-ID to trigger builds. Push a branch with a slightly different format, and the pipeline did nothing. No error, no warning. Just silence.

That kind of thing is easy to solve with documentation. But it catches people during the early days of a migration.

When developers cannot see or influence how the pipeline behaves, the branching strategy on paper and the branching strategy in practice are two different things.

Every repo ends up different

One of the more disorienting things about a migration is that different repositories end up at different stages.

Some repos followed a tag-based deployment model. Others deployed from main only. Some had manual dispatch. Others had strict branch naming triggers. The hotfix path that worked in one repo did not exist in another.

During one incident, the tech lead mentioned that different architects had different expectations about the process. Some assumed one workflow, others assumed another. Everyone was working from a different mental model.

Consistency matters more than having the perfect model. Three different "right" approaches across an organization is harder to manage than one imperfect approach that everyone understands.

What I think about now

After going through this a few times, there are things I look for before a branching strategy switch.

Does the CI pipeline enforce tests as a hard blocker, not a suggestion?

Is there a tested path to ship a hotfix to production without deploying everything in main?

Can developers trigger common deployment operations without filing a ticket?

Is the model consistent across repositories, or does each repo have its own workflow?

Has anyone actually simulated a production hotfix under the new process?

These are not exotic requirements. But in every migration I have been part of, at least a few of them were missing on day one.

They always surfaced at the worst possible time.

Trunk-based development is worth getting to. It just helps to make sure the foundation is there before making the switch.

What broke my JWT flow in Blazor Server and how I fixed it

Prithwiraj Das — Mon, 23 Mar 2026 15:10:13 +0000

Three things I got wrong building my first production Blazor Server app, coming from a background in Angular and traditional ASP.NET.

Originally published on Medium

The one thing you need to understand first

In a standard HTTP app, every user interaction is a new request — new pipeline, new HttpContext, new everything. Blazor Server works differently: the initial page load is an HTTP request, but after that, everything runs over a persistent WebSocket connection (SignalR). There are no further HTTP requests.

This means HttpContext is only reliably available during that first request — once the SignalR circuit is established, it is either null or stale.

Microsoft's documentation puts it plainly:

"IHttpContextAccessor generally should be avoided with interactive rendering because a valid HttpContext isn't always available."

That one sentence explains everything below.

Issue 1 — User metadata cached at the wrong time

What I had:

My UserMetadataService loaded user auth data in the constructor using Task.Run(...).Wait(). Load once, reuse everywhere:

public class UserMetadataService  
{  
    private readonly IHttpContextAccessor _authState;  
    public IUserAuthData userAuthData { get; private set; }  

    public UserMetadataService(IHttpContextAccessor authState)  
    {  
        _authState = authState;  
        Task.Run(LoadUserMetaData).Wait();  
    }  

    private async Task LoadUserMetaData()  
    {  
        var user = _authState.HttpContext?.User;  
        userAuthData = user != null ? new UserAuthData(user.Claims) : null;  
    }  
}

This worked on first load. But for users whose session context needed to be read after circuit establishment — role-based access checks, tenant resolution — the cached value was stale, and for some users it was null entirely.

What fixed it:

Converting userAuthData from a cached property to a computed one:

public sealed class UserMetadataService(IHttpContextAccessor authState)  
{  
    public IUserAuthData userAuthData  
    {  
        get  
        {  
            var user = authState.HttpContext?.User;  
            return user != null ? new UserAuthData(user.Claims) : null;  
        }  
    }  
}

Issue 2 — Reading HttpContext too late in TokenService

This one took longer to find because it only failed intermittently and left almost nothing useful in the logs.

What I had:

My TokenService held a reference to IHttpContextAccessor and read HttpContext inside RefreshTokenAsync() — called whenever a new JWT was needed for an outgoing API request:

public class TokenService : ITokenService  
{  
    private readonly IHttpContextAccessor _httpContextAccessor;  

    public async Task RefreshTokenAsync()  
    {  
        var httpContext = _httpContextAccessor.HttpContext;  
        if (httpContext?.User?.Identity?.IsAuthenticated != true)  
        {  
            _logger.LogWarning("User is not authenticated");  
            _cachedToken = null;  
            _navigationManager.NavigateTo(_navigationManager.Uri, forceLoad: true);  
            return;  
        }  

        var user = httpContext.User;  
        var tokenDescriptor = new SecurityTokenDescriptor  
        {  
            Subject = new ClaimsIdentity(user.Claims.ToArray()),  
            IssuedAt = DateTime.UtcNow,  
            Expires = DateTime.UtcNow.AddMinutes(3),  
        };  
    }  
}

The constructor runs during initial circuit setup, before SignalR takes over. That is the one reliable window to read from HttpContext in a Blazor Server service. Reading it anywhere else — from a method, a timer, a component event — is not safe.

Issue 3 — JwtTokenForwardHandler extending the wrong base class

What I had:

public class JwtTokenForwardHandler : HttpClientHandler { }  

// In Program.cs  
.ConfigurePrimaryHttpMessageHandler(serviceProvider =>  
    serviceProvider.GetRequiredService<JwtTokenForwardHandler>());

HttpClientHandler is the primary transport handler — it owns the socket and the connection pool. Registering it via ConfigurePrimaryHttpMessageHandler tells IHttpClientFactory to treat it as the transport layer, which means it gets pooled and shared across requests. Any user-specific state on that handler can persist across request boundaries.

What fixed it:

public class JwtTokenForwardHandler : DelegatingHandler  
{  
    private readonly ITokenService _tokenService;  

    public JwtTokenForwardHandler(ITokenService tokenService)  
    {  
        _tokenService = tokenService;  
    }  

    protected override async Task<HttpResponseMessage> SendAsync(  
        HttpRequestMessage request,  
        CancellationToken cancellationToken)  
    {  
        var token = await _tokenService.GetCurrentTokenAsync();  
        request.Headers.Authorization =  
            new AuthenticationHeaderValue("Bearer", token);  
        return await base.SendAsync(request, cancellationToken);  
    }  
}  

// In Program.cs  
.AddHttpMessageHandler<JwtTokenForwardHandler>();

A DelegatingHandler is outgoing middleware — it sits in front of the transport layer, adds the token per call inside SendAsync, and passes control down the chain. No state is stored on the handler instance.

What I took away from this

All three of these patterns felt correct when I wrote them. They were correct in every HTTP-based context I had used them in. The shift Blazor Server requires is not obvious from reading the API surface — it only becomes clear once you understand that the circuit model fundamentally changes when HttpContext exists and what service lifetimes mean in that environment.

DEV Community: Prithwiraj Das

The Bugs Were Never in the New Code

The setup

Bug one: a sibling pretending to be a child

Bug two: a heuristic that expired

Bug three: context that fell off a boundary

One mistake, three forms

What AI did and didn't do

The same three mistakes, at backend scale

What I do differently now

Feature Flags Are Not a Free Lunch

The plan is always clean

Why flags become permanent

One flag doing too much

The client matrix problem

Migrating flag platforms

The naming problem

What I think about now

What Goes Wrong When You Switch Branching Strategies Mid-Flight

The switch usually happens fast

The test gap

The hotfix that could not ship

The pipeline is not always in your hands

Every repo ends up different

What I think about now

What broke my JWT flow in Blazor Server and how I fixed it

The one thing you need to understand first

Issue 1 — User metadata cached at the wrong time

Issue 2 — Reading HttpContext too late in TokenService

Issue 3 — JwtTokenForwardHandler extending the wrong base class

What I took away from this

References