DEV Community: Prithwiraj Das

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

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