DEV Community: Caramelo da TI

mcp-scan: a ferramenta que revela riscos que você não vê

Caramelo da TI — Sat, 29 Nov 2025 01:31:03 +0000

Recentemente saiu a nova edição do Tech Radar da Thoughtworks e, dando uma olhada no quadrante de ferramentas no anel Trial, me deparei com uma recomendação de um colega: o servidor MCP Context7. A proposta é bem interessante porque permite que um agente consulte a documentação real de uma tecnologia em vez de simplesmente “chutar” — evitando aquelas alucinações ou respostas mágicas que parecem existir… mas só na imaginação do modelo.

Mas aí surgiu outra dúvida: com tantas recomendações de servidores MCP diferentes, até que ponto é seguro ir adicionando novas tools no seu cliente?

Pesquisando um pouco mais, voltei ao mesmo Tech Radar, mas agora no anel Assess, onde encontrei o mcp-scan.

mcp-scan

O mcp-scan ajuda a identificar vulnerabilidades de segurança como prompt injection, tool poisoning e toxic flows. Ele também permite monitorar o tráfego entre agentes e servidores MCP, ajudando a entender como as tools se comportam em tempo real e evitando ataques escondidos no background.

Configurando o Context7 no Github Copilot pra Jetbrains

A configuração é bem simples. O mais recomendado é gerar uma chave de API criando uma conta na Context7, assim você ganha limites de uso mais generosos.

Configuração visual

Nas IDEs da JetBrains, abra a janela do GitHub Copilot e clique no ícone de ferramentas (Configure Tools).

Depois clique em Add More Tools.

Isso vai abrir o arquivo de configuração com a lista de servidores MCP disponíveis para o Copilot.

Configuração via terminal

Abra o arquivo mcp.json, que fica em: ~/.config/github-copilot/intellij/mcp.json.

Exemplo:

vi ~/.config/github-copilot/intellij/mcp.json

Com o arquivo aberto, basta adicionar a configuração do servidor Context7:

{
    "servers": {
        "context7": {
            "type": "http",
            "url": "https://mcp.context7.com/mcp",
            "headers": {
                "Accept": "application/json, text/event-stream"
            },
            "tools": ["get-library-docs", "resolve-library-id"]
        }
    }
}

Nos exemplos da documentação o header Accept não aparece, mas precisei adicionar porque o servidor também usa text/event-stream.

Depois disso o agente já consegue usar as tools do Context7. A própria documentação recomenda adicionar uma instrução global pedindo para sempre consultar a documentação quando necessário.
Isso pode ser feito em: ~/.config/github-copilot/intellij/global-copilot-instructions.md.

Usando `uv` com `mcp-scan`

O uv é um gerenciador e executor de ambientes Python que facilita muito instalar ferramentas como o mcp-scan. A instalação é bem direta, basta seguir o guia oficial.

Com o uv instalado, para escanear basta rodar:

uvx mcp-scan@latest

Para escanear um servidor específico, como o do GitHub Copilot para JetBrains:

mcp-scan ~/.config/github-copilot/intellij/mcp.json

Como configuramos o servidor MCP da Context7, você deve encontrar uma saída como abaixo:

Também dá para usar o mcp-scan como proxy, monitorando o tráfego em tempo real entre cliente e servidor MCP. Para não alongar demais o post, deixo o trecho da documentação que explica isso aqui.

Resumo

Com a chegada dos agentes e servidores MCP, surgem também novas ameaças. Ter uma ferramenta como o mcp-scan ajuda bastante a manter o ambiente seguro. Mesmo ainda estando na versão v0, é um projeto promissor — e não é à toa que entrou no Tech Radar da Thoughtworks.

Fontes:

Como acompanhar a evolução da tecnologia sem se perder no caminho no mundo "2x"

Caramelo da TI — Sun, 09 Nov 2025 15:19:34 +0000

Nesse mundo em “2x”, estamos sempre correndo. É fácil se sentir atrasado e sobrecarregado com a enxurrada de novidades tecnológicas.
E a IA só acelera esse processo: primeiro vieram as LLMs, depois os agentes de IA, e quando menos esperamos, já estamos ouvindo falar de MCP Servers.

Mas afinal, o quanto dessa montanha de novidades é realmente importante?
O que é hype? E será que vale passar todo o tempo livre tentando acompanhar tudo?

Durante minha trajetória na tecnologia, já me vi (e ainda me vejo) nesse dilema (FOMO).
Neste texto, quero compartilhar como aprendi a lidar com isso e acompanhar o ritmo da tecnologia sem surtar.

A IA acelerando a evolução e o nosso jeito de aprender

A cada semana surgem novas promessas: “a IA vai substituir pessoas”, “vai multiplicar a produtividade”… e, em parte, é verdade.
Mas é importante se perguntar: até onde a IA deve fazer por você?

Com a velocidade que ela impõe, pode ser tentador “combater fogo com fogo”. Mas dessa forma quem está aprendendo? É você ou a IA?

Durante o Workshop do Instituto de Inteligência Artificial (LNCC, 2025) , Patrick Valduriez trouxe uma reflexão poderosa:

Em que ponto a IA deixa de ser copiloto e passa a ser piloto?
E o que isso muda na forma como aprendemos e decidimos?

A IA é uma aliada incrível, mas ainda é uma ferramenta e cabe a você usá-la com propósito.
Durante os estudos, use-a para entender a solução, não apenas para obter a solução. Assim, você aprende de fato, e não só “acerta”.

Vale lembrar: as respostas de uma LLM são limitadas ao conhecimento com o qual foi treinada, e nem sempre estão corretas. Uma LLM não pensa, ela calcula a probabilidade da próxima palavra (token) ser a que esperamos. Existe sempre uma zona escura, onde talvez nem saiba responder (ainda).
E é aí que entra a verdadeira curiosidade humana.

O que você domina, o que conhece e o que ainda não conhece

Antes de mais nada, vale esclarecer:

O que você domina: é o conhecimento que usa no dia a dia, fala sobre com segurança e aplica com naturalidade.
O que você conhece, mas não domina: sabe que existe, entende o conceito, mas não saberia aplicar de imediato.
O que você não conhece: está fora da sua bolha, e justamente por não conhecer, não sabe que não sabe.

Essa preocupação em “estar em dia” não é nova.
Há alguns anos, levantei essa questão com meu amigo e mentor MSc. Augusto José Moreira da Fonseca, e ele me disse algo que nunca esqueci:

“Você não precisa aprender tudo. Mas conheça o máximo do que existe e para que serve, adicionando ao seu cinto de utilidades.
Assim, quando o problema aparecer, você saberá que ferramenta usar e aí, sim, vai aprender a fundo.”

Na prática

Imagine que todo o conhecimento em tecnologia seja representado por um triângulo.

A parte verde — pequena — é o que dominamos.
Ela cresce com tempo e prática, mas exige energia e constância. Se for algo que não usamos, esquecemos rapidamente.

Por isso, a energia deve estar voltada a expandir a parte amarela: o que conhecemos, mas ainda não dominamos.
Trazer luz ao desconhecido, entender para que serve e quando serve cada coisa, e assim montar o seu “cinto de utilidades”.

Regra dos 30 minutos

Separe 30 minutos por dia só para mapear o que está acontecendo:
leia títulos de blogs (O’Reilly Radar, Azure Blog, AWS Blog, dev.to, etc.), veja vídeos de referência, siga repositórios do GitHub de tecnologias e empresas que você acompanha (Microsoft, Vercel, Meta…).

Se algo chamar atenção, leia ou assista com foco nos porquês e quandos.
Entenda o contexto e o problema que aquela tecnologia ou técnica resolve.

💡 Nesse momento, você filtra o que tem real aplicabilidade pra você.
É legal entender como criar uma linguagem do zero, mas talvez não seja prioridade ou não tenha tanta aplicabilidade se você é um dev web júnior.

Assim, você expande a parte “o que conhece, mas não domina”, sem se perder no mar de novidades.

Para quem acredita que 'santo de casa não faz milagres', Mark Richards, autor de Fundamentals of Software Architecture dentre outros, explica esse mesmo conceito de forma mais detalhada em sua série Developer to Architect — Lesson 3: Gaining Technical Breadth.

É importante entender que essa estratégia não significa que não precisa se aprofundar em nenhum tópico. Mas sim que dessa forma, é possível dedicar tempo e energia de forma estratégica nos estudos e ciente do que existe, caso precise.

Carta para iniciantes na área

Quando comecei na tecnologia, me assustei com a quantidade de coisas novas, parecia impossível acompanhar.
E adivinha? É impossível mesmo. 😄

Mas tudo bem. Você não precisa ser especialista em tudo.

Uma das principais características do ser humano é a curiosidade e a capacidade de aprender.

Assim como capacidades físicas, exige exercício para chegar a sua melhor performance.
Se você faz musculação por exemplo, entende que precisa treinar frequentemente e também dar um tempo de descanso. Não é diferente com a nossa capacidade de aprender.

Comece pelos fundamentos, eles quase nunca mudam.
Os princípios da Orientação a Objetos, por exemplo, são praticamente os mesmos desde os anos 1960.
Aprenda uma linguagem e framework, e já terá meio caminho andado para outras linguagens e frameworks.
Logo perceberá que muito do conhecimento é transferível.

Eu comecei com PHP e jQuery.
Meu primeiro trabalho foi com Laravel e Angular.
Depois, migrei para .NET, e percebi que os conceitos se repetem: Eloquent no Laravel, Entity Framework Core no .NET, SQLAlchemy no Python, entre outras coisas.
A ideia é a mesma, só muda a sintaxe e alguns detalhes.

Utilize sim IA para estudar, mas use consciente.

⚠️ Se você é um desenvolvedor e pede para um agente criar para você a implementação de alguma funcionalidade, entenda, você ainda é responsável pelo código gerado e tem a obrigação profissional de responder por ele. O mesmo se aplica a outros papéis. Entenda o que foi feito e o porquê.

Como estudante autodidata, acaba caindo por sua própria responsabilidade a condução até o conhecimento, que antes seria responsabilidade de um mentor.

Dê tempo para você processar a informação, descanse.
Arquitetos, programadores, profissionais de tecnologia em geral exercem uma atividade intelectual. Não é quantidade de cliques ou tempo em frente de tela que define sua produtividade.

Quem nunca teve aquela ideia que resolve o problema enquanto lava uma louça, faz uma atividade fora ou mesmo dormindo?!

E talvez o conselho mais valioso: escreva, compartilhe, explique para alguém.
Ao ensinar, você descobre novas dúvidas, e consolida o aprendizado de verdade.

Fontes

Obs: texto revisado por IA 🤖😁🦾

Gerenciamento Feature Flag em Azure Functions

Caramelo da TI — Tue, 04 Nov 2025 19:17:58 +0000

O que é Feature Flag?

Feature flag é uma técnica que permite habilitar ou desabilitar funcionalidades de forma dinâmica, sem a necessidade de alteração no código. Essencialmente, funciona como um "interruptor" (ou "toggle" ou "flag") que controla o comportamento de uma aplicação.

O uso dessa técnica facilita a gestão de novas atualizações, impacto de dependência de publicação coordenada entre times, além de permitir estratégias de experimentação de novas funcionalidades ou otimizações.

Configurando o Microsoft.FeatureManagement em Azure Functions

Dependendo do seu caso, pode ser que a velha variável de ambiente resolva ou alguma implementação customizada, contudo o pacote Microsoft.FeatureManagement atende tanto o cenário mais simples, quanto um mais complexo, pois já tem built-in várias funcionalidades como estratégia de distribuição de variantes, tempo de disponibilidade de uma funcionalidade entre outros. E também vale ressaltar sua capacidade de customização, permitindo criar a sua regra de como e quando determinada feature-flag deve estar habilitada ou não.

Nesse exemplo estarei usando uma Azure Function in-process com .Net 8 para exemplificar a configuração e uso do pacote Microsoft.FeatureManagement de forma prática. O fundamento aqui serve para outros modelos de aplicação .Net, mas o básico aqui dá para ter um pontapé inicial.

O primeiro exemplo que encontramos na documentação é usando o recurso App Configuration que centraliza o gerenciamento de configurações e feature flags da aplicação.
Para isso é necessário criar o recurso, na primeira interação precisará atribuir o papel de owner e então conseguirá editar e acessar as chaves de conexão.

Feito isso é possível configurar a conexão na aplicação

using System;
using Caramelo.FoodDispenser;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Configuration.AzureAppConfiguration;
using Microsoft.FeatureManagement;

[assembly: FunctionsStartup(typeof(Startup))]
namespace Caramelo.FoodDispenser;

public class Startup : FunctionsStartup
{
    public override void ConfigureAppConfiguration(IFunctionsConfigurationBuilder builder)
    {
        builder.ConfigurationBuilder.AddAzureAppConfiguration(options =>
        {
            var connString = Environment.GetEnvironmentVariable("AZ_APP_CONFIG_CONN");
            options
                .Connect(connString)
                .Select("_")
                .UseFeatureFlags();
        });
    }

    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddAzureAppConfiguration();
        builder.Services.AddFeatureManagement();
    }
}

💡

O método .Select("_") é usado apenas para exemplificação — ele filtra todas as chaves começando com o prefixo _, o que na prática ignora as demais chaves do App Configuration.Mais detalhes sobre isso Aqui.

Em produção, a variável de ambiente AZ_APP_CONFIG_CONN deve ser configurada nos Application Settings do Function App. Mais detalhe sobre isso Aqui

O exemplo usa Azure Functions in-process (.NET 8), mas a configuração é muito semelhante no modelo Isolated, mudando apenas a forma de injeção de dependências.

Na implementação vamos criar a function Http Trigger

using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Microsoft.FeatureManagement;
using Newtonsoft.Json;

namespace Caramelo.FoodDispenser;

public class FeedDog(IFeatureManagerSnapshot featureManager)
{
    [FunctionName("FeedDog")]
    public async Task<IActionResult> RunAsync(
        [HttpTrigger(AuthorizationLevel.Anonymous,  "post", Route = "feed")]
        HttpRequest req,
        ILogger log)
    {
        var requestBody = await new StreamReader(req.Body).ReadToEndAsync();
        var data = JsonConvert.DeserializeObject<FeedingRequest>(requestBody);
        int portions;

        if (await featureManager.IsEnabledAsync("GreedyMode"))
        {
            log.LogInformation("Greedy Mode activated 🥩 — doubling portion!");
            portions = data.Portions * 2;
            await DispenseFood(data.DeviceId, portions);
        }
        else
        {
            log.LogInformation("Normal Mode 🍖 — regular portion.");
            portions = data.Portions;
            await DispenseFood(data.DeviceId, portions);
        }


        return new OkObjectResult(new FeedingResponse(data.DogName, data.DeviceId, portions));
    }
    private static Task DispenseFood(string deviceId, int portions)
    {
        // lógica simulada
        return Task.CompletedTask;
    }
}

public record FeedingRequest(string DogName, string DeviceId, int Portions);
public record FeedingResponse(string DogName, string DeviceId, int Portions);

O principal está na injeção de IFeatureManagerSnapshot e seu uso em await featureManager.IsEnabledAsync("GreedyMode").
Nesse trecho estamos verificando se a feature flag GreedyMode está habilitada e aplicando o comportamento alternativo.

💡 É possível usar o IFeatureManager ao invés do IFeatureManagerSnapshot, contudo o segundo faz com que as configurações de features flags sejam consistentes em tempo de requisição. Ou seja, mesmo que dois serviços injetem a classe e ela troque de valor em tempo de requisição, será sempre considerado o valor inicial.

Mas para que funcione conforme esperado, antes é necessário cadastrar essa feature flag.

Cadastrando uma feature flag no App Configuration

De volta ao Portal Azure, acessando o recurso App Configuration é possível encontrar a opção Feature manager:

Clicando nela, na parte superior existe um botão Criar que ao clicar apresenta duas opções Feature Flag e Variant Feature Flag. Sem entrar muito em detalhes, ambas são muito parecidas, mas a segunda permite que tenha mais estados que On e Off, adicionando mais variações. Vamos focar na primeira mesmo nesse exemplo.

Na tela de criação é possível adicionar algumas descrições para facilitar a identificação do motivo da feature flag e efeito na aplicação, mas o importante para a aplicação é o atributo Key.
O nome da Key deve corresponder exatamente ao valor usado em IsEnabledAsync().

🐞 Não recebi nenhum erro ao criar com uma Key com nome composto separado por espaço, mas pode gerar confusão, então recomendo escolher sua convenção favorita e adotar ela. Atenção também com espaços no final da Key (Sim eu sofri com isso).

Filtros

Ainda na tela de criação existe a opção de adicionar filtros, caso marque o checkbox e clique no botão Criar irá ser exibido o menu para configuração do filtro.

A funcionalidade já possui 2 tipos de filtros built-in, Time window e Targeting.

Time window: permite que a feature flag, se habilitada, só tenha efeito durante uma janela de tempo configurada.
Targeting: permite que a feature flag, se habilitada, só tenha efeito para usuários ou grupos especificados.

💡 Existem outros tipos de filtro built-in não disponíveis por padrão na interface do App Configuration.

Também é possível criar o seu próprio filtro, de forma com que a aplicação saiba interpretar e aplicar o comportamento esperado.

Para esse exemplo não será aplicado nenhum filtro

Habilitando e desabilitando uma feature flag

Criada a feature flag é possível observar o resultado da operação conforme configurado no App Configuration.

Greedy Mode activated 🥩 — doubling portion!

Desabilitando:

temos a seguinte saída:

Normal Mode 🍖 — regular portion.

Embora o exemplo seja simples, o fundamento se aplica em outros cenários mais complexos.

Alternativas ao App Configuration

As configurações de feature flags podem ser por App Configuration, mas também podem ser configuradas no local.settings.json,appsettings.json ou a partir de outra origem customizada.

A configuração do Microsoft.FeatureManagement é a partir da interface IConfiguration, o que faz com que seja fácil prover conforme sua aplicação já o faz.

Internamente o pacote irá tentar resolver as feature flags procurando nas configurações as chaves conforme a seguinte representação:

{
    "feature_management": {
        "feature_flags": [
            { "id": "FeatureA", "enabled": true },
            { "id": "FeatureB", "enabled": false }
        ]
    }
}

FeatureManagement.Dotnet.v1.0.0.schema.json

Contudo também é possível indicar qual a Section customizada você configurou:

services.AddFeatureManagement(configuration.GetSection("CarameloFeaturesFlags"));

local.settings.json

Caso use o local.settings.json vale lembrar que os delimitadores hierárquicos são __ ou ::, por exemplo:

{
  "Values": {
    "feature_management::feature_flags:0:id": "FeatureA",
    "feature_management::feature_flags:0:enabled": true,
    "feature_management::feature_flags:1:id": "FeatureB",
    "feature_management::feature_flags:1:enabled": false
  }
}

Alternativa customizada

Particularmente não gosto do padrão de delimitadores de Azure Functions, mas isso por si só não seria motivo de aumentar a complexidade.
Contudo caso precise integrar as flags com um CMS interno, banco ou painel próprio e o App Configuration não seja uma opção, é possível customizar um outro provedor das features flags.
Mas falar é fácil, vamos ao código.

Para prover uma opção customizada deve-se implementar a interface IFeatureDefinitionProvider.

Essa interface obriga implementar 2 métodos, GetAllFeatureDefinitionsAsync() que retorna todas as features flags configuradas e GetFeatureDefinitionAsync(string featureName) que obtém uma feature flag pelo seu nome.

Uma abordagem mais interessante para obter o mesmo dinamismo que o App Configuration possui, seria implementar utilizando algum recurso de armazenamento como banco de dados, dessa forma é possível alterar os valores em necessidade de alterar a aplicação ou uma nova publicação, mas para fins de exemplificação é possível implementar utilizando um arquivo json para a configuração.

{
  "featureFlags": [
    {
      "id": "FeatureA",
      "enabled": true
    },
    {
      "id": "FeatureB",
      "enabled": false
    }
  ]
}

E implementando a interface IFeatureDefinitionProvider:

using System;
using System.Collections.Generic;
using System.IO;
using System.Threading.Tasks;
using Microsoft.FeatureManagement;
using Newtonsoft.Json;

namespace Caramelo.FoodDispenser;

public class JsonFileFeatureFlagDefinitionProvider(string appRootPath) : IFeatureDefinitionProvider
{
    private const string FeatureFlagFileName = "feature-flags.json";
    public async Task<FeatureDefinition> GetFeatureDefinitionAsync(string featureName)
    {
        await foreach (var featureDefinition in GetAllFeatureDefinitionsAsync())
        {
            if (featureDefinition.Name.Equals(featureName, StringComparison.OrdinalIgnoreCase))
            {
                return featureDefinition;
            }
        }
        return null;
    }

    public async IAsyncEnumerable<FeatureDefinition> GetAllFeatureDefinitionsAsync()
    {
        var path = Path.Combine(appRootPath, FeatureFlagFileName);
        string featureFlagsJson = await File.ReadAllTextAsync(path);
        var featureManagementConfig = JsonConvert.DeserializeObject<FeatureManagementConfig>(featureFlagsJson);

        foreach (var featureFlag in featureManagementConfig.FeatureFlags)
        {
            yield return new FeatureDefinition
            {
                Name = featureFlag.Id,
                EnabledFor = featureFlag.Enabled ? [new() { Name = "AlwaysOn", }] : [],
            };
        }
    }
    internal struct FeatureManagementConfig
    {
        public FeatureFlag[] FeatureFlags { get; set; }
        internal struct FeatureFlag
        {
            public string Id { get; set; }
            public bool Enabled { get; set; }
        }    
    }
}

Manutenção e escalabilidade

O uso de feature flags é uma abordagem que pode facilitar o gerenciamento de versões de sua aplicação, mas também um aliado a experimentação e mitigação de risco.

É possível reduzir o risco de uma publicação de nova versão aplicando a técnica Canary Release, realizar experimentos a fim de obter insights e dados coletados através de Teste A/B e também ter uma rápida resposta caso alguma coisa não esteja funcionando como esperado (Graceful Degradation).

O Microsoft.FeatureManagement facilita as abordagem citadas já com seus filtros built-in(PercentageFilter, TimeWindowFilter, TargetingFilter). Vale a pena dar uma conferida também na documentação o quanto é possível customizar os filtros. Ainda usando o App configuration ao editar uma regra, existe a opção Advanced Edit que permite customizar ainda mais os filtros já existentes. As mesmas customizações são possíveis de fazer usando outro método de configuração das features flags.
Tudo isso permite lançar features de forma incremental e controlada, reduzindo riscos de publicação.

Deixando o código mais elegante:

Um ponto que particularmente me incomoda é precisar aplicar uma condicional para a feature flag, interrompendo do encadeamento de ideias ao analisar um código. Contudo para aplicações mais simples, essa estratégia se prova suficiente.

A simplicidade é o último grau de sofisticação - atribuída a Leonardo Da Vinci

Mas, conforme a aplicação cresce, pode ser necessário adotar estratégias mais sofisticadas para desacoplar a lógica de decisão da lógica de negócio, conforme abordado por Pete Hodgson no artigo
Feature Toggles, onde apresenta estratégias para desacoplar os pontos de tomada de decisão dos de lógica, levando em consideração a gestão das features flags com o crescimento saudável da aplicação.
Não vou abordar esse tema, mas cabe a você avaliar o impacto e crescimento e complexidade da aplicação, para decidir se vale ou não aplicar alguma técnica para melhorar a manutenção das features flags.

Fontes

Should I wait or should I go?! Quando usar .ConfigureAwait() em Tasks .Net?

Caramelo da TI — Mon, 03 Nov 2025 17:46:56 +0000

Para que serve?

Antes de falar do tópico principal, vamos falar do famigerado tipo Task.

Task-based asynchronous pattern e o tipo Task

A Task surgiu junto do Task-based asynchronous pattern (TAP)
, que simplifica a representação da inicialização e conclusão de uma operação assíncrona.
O TAP foi incluído no .NET Framework 4 e desde então é a forma recomendada de lidar com programação assíncrona e introduziu o namespace System.Threading.Tasks
e, com ele, o tipo Task, cuja finalidade é representar uma operação assíncrona.

Uma Task representa uma operação que eventualmente produzirá um resultado, poderá falhar (lançar exceção) ou ser cancelada.
Ela é essencialmente um contêiner que descreve o andamento e o estado da operação assíncrona.

O que vem depois do `await`?

Uma vez invocado um método que gera uma operação assíncrona, essa operação será executada de forma independente, e podemos usar o operador await para suspender a execução até que o resultado esteja disponível.

Vamos considerar o exemplo:

public async Task GetData(object params)
{
    var validParams = Validate(params);
    var data = await _service.DoSomething(validParams);
    UpdateUI(data);
}

No código acima, o compilador divide o método em duas partes: antes e depois do await.
Antes do await temos a parte síncrona, e depois do await temos a continuação (continuation).

Essa continuação pode ou não ser executada em outra thread, depende do contexto e do estado da Task.
Se a Task já estiver concluída, a continuação pode ocorrer na mesma thread; se não, pode ocorrer em uma thread diferente.

Durante a geração desse código, o compilador captura o contexto atual, que pode ser:

Um UI Context (WPF, WinForms),
Um ASP.NET request context (ASP.NET clássico),
Ou simplesmente nenhum contexto, como em ASP.NET Core ou Console Apps.

Esse contexto é representado pelo objeto SynchronizationContext.
De forma simplificada, ele é responsável por orquestrar a execução assíncrona e decidir em qual thread a continuação do await será executada.

Ok, e o `.ConfigureAwait()`?

É aqui que entra o nosso amigo ConfigureAwait(bool).
Esse método recebe um parâmetro booleano chamado continueOnCapturedContext, e indica se o código após o await deve ou não voltar ao contexto original capturado.

true (padrão): a continuação é executada de volta ao contexto original (por exemplo, a thread da UI).

false: a continuação é executada em qualquer thread disponível do ThreadPool, sem retornar ao contexto original.

Por padrão, o valor é true, ou seja, todo código após o await tenta continuar no mesmo contexto em que a Task foi chamada.

`.ConfigureAwait(false)` sempre então! Certo?!

Você pode estar pensando:

“Se eu não importo que meu código seja continuado em outra thread, posso poupar o SynchronizationContext do trabalho e ganhar performance, não bloqueando a thread principal. Então vou usar .ConfigureAwait(false) sempre!”

Essa é uma conclusão comum, e equivocada.
De fato, muita gente passou a usar .ConfigureAwait(false) em todo lugar após ler recomendações como as de Stephen Cleary em Async/Await Best Practices.

No entanto, o uso indiscriminado pode causar bugs difíceis de rastrear, especialmente quando diferentes pessoas mantêm o código sem entender o motivo do uso.

Em muitos casos, remover um .ConfigureAwait(false) antigo resolve um bug misterioso, o tipo de problema “isso estava aqui desde 2010 ninguém entende o porquê”.

Além disso, não há ganho de performance perceptível ao usar false; o benefício está em evitar dependência do contexto (por exemplo, para evitar deadlocks em bibliotecas reutilizáveis).

O que pode dar errado?

Vamos supor que temos o código inicial, que roda em uma aplicação WinForms ou WPF, mas agora adicionamos o .ConfigureAwait(false):

public async Task GetData(object params)
{
    var validParams = Validate(params);
    var data = await _service.DoSomething(validParams)
                             .ConfigureAwait(false);
    UpdateUI(data);
}

Nesse caso, o UpdateUI(data) será executado em uma thread diferente da principal.
Como apenas a thread da UI pode atualizar elementos visuais, isso resultará na seguinte exceção:

System.InvalidOperationException: 'The calling thread cannot access this object because a different thread owns it.'

Ou seja, .ConfigureAwait(false) foi usado de forma incorreta.
O próprio Stephen Cleary destacou isso em uma resposta no StackOverflow.

Mesmo fora de aplicações gráficas, .ConfigureAwait(true) pode causar deadlocks, especialmente no ASP.NET Framework clássico, onde cada requisição possui seu próprio SynchronizationContext.

Exemplo:

public class RandomLibraryService
{
    public async Task<string> GetDataAsync()
    {
        // ⚠️ Usa o contexto original (continueOnCapturedContext = true)
        await Task.Delay(1000);
        return "Hello World!";
    }
}

// ASP.NET Framework, não Core
public class HomeController : Controller
{
    private RandomLibraryService _rls;

    public string Index()
    {
        // ⚠️ Chamando async de forma síncrona
        return _rls.GetDataAsync().Result;
    }
}

Aqui, a requisição HTTP é associada a um AspNetSynchronizationContext.
Quando Index() chama GetDataAsync().Result, a thread da requisição é bloqueada.
O método GetDataAsync() libera a thread e registra a continuação para o mesmo contexto capturado, que está bloqueado, gerando um deadlock.

Mesmo fora de ambientes de UI, isso ocorre porque o código tenta retornar ao contexto original, que está indisponível.

Em ambientes modernos como ASP.NET Core, isso não acontece, pois o SynchronizationContext foi removido.

Quando usar `.ConfigureAwait(false)`?

✅ Em bibliotecas e pacotes reutilizáveis, pois você não controla o contexto do chamador.
Isso evita depender de um SynchronizationContext desconhecido.
⚠️ Em código de aplicação, normalmente não há necessidade de usá-lo.
O comportamento padrão (true) é mais previsível e seguro.

Stephen Toub (Microsoft) reforça isso no ConfigureAwait FAQ:

“If you’re writing app-level code, do not use ConfigureAwait(false).”

Conclusão

Quando await espera uma Task, o comportamento padrão é capturar um contexto, que pode ser um SynchronizationContext, ou na ausência dele, o TaskScheduler.Current.
Quando a Task termina, o código após o await é executado nesse contexto capturado (.ConfigureAwait(continueOnCapturedContext: true) é o comportamento padrão).

Usar .ConfigureAwait(false) instrui o runtime a não retornar ao contexto capturado, permitindo que o código continue em qualquer thread disponível do thread pool.

Isso não significa que o código após o await sempre rodará em outra thread, isso só acontece se o await realmente suspender a execução (ou seja, se a Task ainda não estiver concluída).

A dica final é, se não está desenvolvendo um pacote de uso geral, ou lidando com uma implementação customizada de SynchronizationContext, muito provável que não precise usar .ConfigureAwait().

DEV Community: Caramelo da TI

mcp-scan: a ferramenta que revela riscos que você não vê

mcp-scan

Configurando o Context7 no Github Copilot pra Jetbrains

Configuração visual

Configuração via terminal

Usando uv com mcp-scan

Resumo

Fontes:

Como acompanhar a evolução da tecnologia sem se perder no caminho no mundo "2x"

A IA acelerando a evolução e o nosso jeito de aprender

O que você domina, o que conhece e o que ainda não conhece

Na prática

Regra dos 30 minutos

Carta para iniciantes na área

Fontes

Gerenciamento Feature Flag em Azure Functions

O que é Feature Flag?

Configurando o Microsoft.FeatureManagement em Azure Functions

Cadastrando uma feature flag no App Configuration

Filtros

Habilitando e desabilitando uma feature flag

Alternativas ao App Configuration

local.settings.json

Alternativa customizada

Manutenção e escalabilidade

Deixando o código mais elegante:

Fontes

Should I wait or should I go?! Quando usar .ConfigureAwait() em Tasks .Net?

Para que serve?

Task-based asynchronous pattern e o tipo Task

O que vem depois do await?

Ok, e o .ConfigureAwait()?

.ConfigureAwait(false) sempre então! Certo?!

O que pode dar errado?

Quando usar .ConfigureAwait(false)?

Conclusão

Fontes:

Usando `uv` com `mcp-scan`

O que vem depois do `await`?

Ok, e o `.ConfigureAwait()`?

`.ConfigureAwait(false)` sempre então! Certo?!

Quando usar `.ConfigureAwait(false)`?