DEV Community: Darell Estren

Multi-tenant Angular deployments: CloudFront vs Cloudflare Pages

Darell Estren — Tue, 25 Aug 2026 20:19:44 +0000

The decision is not CloudFront versus Cloudflare Pages

The real decision is what must be isolated per tenant. One Angular build can serve several hostnames when the edge identifies the host and the application receives tenant context. You can also publish one build per tenant, with its own project, domain, and version. Both can be correct; they solve different operational boundaries.

Shared build: one release, one artifact, and hostname routing at the edge.
Independent deployment: one artifact and one release per tenant.

Shared build:
  school.example.test ─┐
                        ├─> edge: identifies host ─> shared build
  clinic.example.test ─┘

Independent deployments:
  school.example.test ─> Angular app (deployment per tenant)
  clinic.example.test ─> Angular app (deployment per tenant)

💡 The original post has an interactive diagram of both models — see it here.

Compare the boundary that matters

Criterion	Shared build with hostname routing	Independent deployment per tenant
Tenant isolation	Must live in authentication, authorization, data, and backend configuration; the bundle is not a security boundary.	Adds artifact and release separation, but does not replace authorization or data controls.
Routing	The CDN or an edge function resolves `school.example.test` and serves the same frontend with tenant context.	Each hostname maps to its own publication; the frontend can include tenant-specific configuration.
Release independence	Low: one shared version reaches everyone.	High: one tenant can be published, paused, or rolled back without changing others.
Caching and domains	A common policy simplifies the platform; it requires discipline to avoid mixing content or responses by host.	Policies and domains are managed per tenant; there are more surfaces to review.
Operations	Fewer pipelines, artifacts, and deployment points.	More projects or distributions, configuration, verification, and automation.

Do not turn this table into a promise of automatic isolation. For example, an independent build does not stop an API from returning another tenant's data if the server accepts an identifier without validating identity. The security boundary belongs where the request is authorized and its data is filtered.

Model 1: one Angular build, multiple hostnames

This model fits when tenants share a product, code, and release calendar. The edge receives a hostname such as school.example.test and routes the request to the same static artifact. Angular can read configuration context at startup; the backend remains responsible for validating the tenant and user on every call.

The design is small, but it needs clear rules:

Do not trust only a browser-supplied hostname. The backend should derive or validate the tenant against identity, an allowed domain, and permissions.
Separate tenant-dependent content. If an API response, generated HTML, or redirect varies by host, the cache key and headers must respect that variation.
Keep the Angular shell updateable. index.html and service-worker manifests often need a different policy from hashed assets. That lets the application discover a new version without leaving the entry page stale.
Test deep links. The CDN needs to serve the SPA entry point for Angular Router routes; otherwise a refresh on an internal URL can return a 404.

CloudFront commonly models this pattern with origins, cache behaviors, edge functions, and domains associated with a distribution. You do not need an edge function when the origin and content are identical for every hostname, but you still need to decide where tenant context is obtained and validated.

Model 2: one deployment per tenant

One Cloudflare Pages project—or a separate distribution and origin—per tenant fits when the artifact must change independently: a build configuration, integration, maintenance window, or isolated rollback.

The main advantage is delivery, not security. You can keep school.example.test on one publication while clinic.example.test receives another. The operational cost is that every tenant needs reproducible build configuration, domain setup, caching, SPA fallback, and post-deployment verification.

In Cloudflare Pages, SPA fallback and cache headers can be declared as static files in the build output. Avoid overlapping header rules when the provider combines values rather than replacing them: a precise rule per path is easier to verify. Custom domains also need to be checked against the correct project; a page may return successfully while still serving another tenant's build when the domain points to the wrong publication.

How to choose without over-designing

Choose a shared build when every tenant can accept the same version at the same time and the real differences are data, permissions, and server-validated configuration. It has fewer artifacts and fewer repeated steps.

Choose independent deployments when you need any of these operational guarantees:

release, roll back, or freeze one tenant without affecting others;
compile configurations that should not coexist in the same artifact;
validate a tenant's domain, integration, or cache behavior before publishing;
delegate operation of one publication without handing over control of the whole platform.

You can start with a shared build and split only tenants that demonstrate a need for independence. Reversing that creates a matrix of pipelines and domains before anyone needs it.

Release checklist

Before publishing either model, verify:

[ ] The backend authorizes both user and tenant; hostname is not the only proof.
[ ] Angular internal routes survive a browser refresh.
[ ] index.html and update files are not trapped in a long cache.
[ ] Hashed assets can reuse cache without hiding a new shell version.
[ ] Every custom domain serves the expected artifact.
[ ] Rollback has an identifiable artifact or publication and a post-rollback check.

Conclusion

CloudFront and Cloudflare Pages are delivery mechanisms; the multi-tenant model defines the boundary you operate. Share a build when you share releases, and separate deployments when you need true publishing independence. In both cases, keep data isolation and authorization in the backend, where they can be verified on every request.

Originally published on DevEdge Blog.

Angular cache bugs after switching user context

Darell Estren — Tue, 25 Aug 2026 20:19:10 +0000

The bug: the API was correct, but the user saw data from another context

A cache often breaks after switching user, tenant, active account, or permission set. The screen requests the same endpoint and the cache responds quickly—but that response belongs to the previous context.

The cause is not Angular or HttpClient. It is a key that does not represent the result. If a response depends on contextId, a URL-only key incorrectly claims that both requests are equivalent.

	Incomplete key (`GET /api/summary`)	Composite key (`summary:{contextId}`)
Context A	`GET /api/summary` → response A	`summary:context-a` → response A
Context B	`GET /api/summary` → HIT: reuses A's response — stale data	`summary:context-b` → response B

💡 The original post has an interactive demo of this comparison — try it here.

The rule is simple: a cache key must include every input that can change the result. That commonly means route, normalized parameters, current user or tenant, locale, relevant permissions, and a data version when applicable. Do not add decorative values; include only real result dependencies.

A small service with a composite key

This example keeps an in-memory cache. The service that knows about a context transition explicitly invalidates it; stale entries do not survive by accident.

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable, shareReplay } from 'rxjs';

interface Summary {
  total: number;
}

@Injectable({ providedIn: 'root' })
export class SummaryCache {
  private contextId = '';
  private readonly entries = new Map<string, Observable<Summary>>();

  constructor(private readonly http: HttpClient) {}

  setContext(contextId: string): void {
    if (contextId === this.contextId) return;
    this.contextId = contextId;
    this.entries.clear();
  }

  getSummary(filter: string): Observable<Summary> {
    const normalizedFilter = filter.trim().toLowerCase();
    const key = `summary:${this.contextId}:${normalizedFilter}`;
    const cached = this.entries.get(key);

    if (cached) return cached;

    const request = this.http
      .get<Summary>('/api/summary', { params: { filter: normalizedFilter } })
      .pipe(shareReplay({ bufferSize: 1, refCount: true }));

    this.entries.set(key, request);
    return request;
  }
}

The important part is not the Map; it is identity. Different contexts or filters produce different keys. setContext clears entries whenever the identity source changes, which also prevents sensitive data from remaining available longer than needed.

A full application restart on sign-out may incidentally clear an in-memory cache. Do not rely on that: the bug returns with a tenant picker, administrative impersonation, a permission update, or persistent storage.

Diagnose it safely

Start without exposing real data.

Reproduce with two test contexts and distinct synthetic responses, such as response A and response B.
Log or inspect only the key shape: route, normalized filters, and a synthetic context identifier.
Switch context without reloading the application, then verify whether the second request gets a HIT for a key that omits context.
Review every cache reader and invalidator. Fixing one component leaves sibling paths exposed.

Do not log response bodies, tokens, or real identifiers. The diagnosis only needs to prove that two different results use the same key.

Tests that catch the regression

The smallest useful tests verify identity and invalidation—not the Map implementation. Each test creates its own cache and fake HTTP client, so it can run in isolation.

it('does not reuse a summary after the context changes', () => {
  const { cache, fakeHttp } = createSummaryCacheWithFakeHttp();

  cache.setContext('context-a');
  cache.getSummary('open').subscribe();

  cache.setContext('context-b');
  cache.getSummary('open').subscribe();

  expect(fakeHttp.urls).toEqual(['/api/summary', '/api/summary']);
});

it('reuses the same request inside one context', () => {
  const { cache, fakeHttp } = createSummaryCacheWithFakeHttp();

  cache.setContext('context-a');
  cache.getSummary('open').subscribe();
  cache.getSummary(' OPEN ').subscribe();

  expect(fakeHttp.urls).toHaveLength(1);
});

Add one case for every dimension that changes a result: tenant, locale, filter, role, or version. If a dimension is absent from the key, the test must prove it cannot change the response; otherwise, include it.

Common pitfalls

Pitfall	Why it fails	Smallest correction
URL-only key	Two contexts share one entry	Add context identity to the key
Clear only on sign-out	Tenant or permission changes retain old data	Invalidate on every context transition
Use unnormalized objects as keys	Ordering and whitespace create duplicate entries	Normalize values before composing the key
One global, unscoped cache	One screen shares data with another	Keep cache ownership close to its data domain
Rely on TTL alone	Incorrect data remains possible during the TTL	Explicitly invalidate on context change

A TTL controls age; it does not correct identity. The key prevents incorrect data from entering, and invalidation removes data that is no longer valid.

Checklist

[ ] The key includes every input that changes the result.
[ ] Values are normalized before the key is created.
[ ] Every user, tenant, permission, or account transition invalidates the affected domain.
[ ] Tests cover a HIT within one context and a MISS across contexts.
[ ] Diagnostic logs use synthetic values and contain neither responses nor credentials.

Originally published on DevEdge Blog.

Terraform Says the Resource Already Exists: Recover State Ownership

Darell Estren — Tue, 25 Aug 2026 20:19:09 +0000

The problem is not that Terraform cannot create the resource

An AlreadyExists, AlreadyAssociated, or creation conflict often triggers the wrong response: delete something and run apply again. Do not do that. Terraform is not necessarily saying the infrastructure is wrong; it is saying it is trying to create something the provider already knows about while its state does not consider it owned.

The right question is not "how do I delete it?" It is: which real object exists, who should manage it, and what does the state represent today?

Terraform works with two sources of truth: configuration defines desired state, and state records which remote objects each resource address manages. When an object exists but that relationship is missing from state, Terraform plans a create. The provider rejects it because the object—or an exclusive relationship such as an association—already exists.

In short, the recovery cycle has four steps:

The remote resource exists — the provider already knows the object, even though Terraform does not yet manage it from this address.
Terraform plans to create it — without state ownership, configuration proposes a create that the provider rejects.
Import establishes ownership — import links the existing object to the correct state address without modifying the remote resource.
The reviewed plan reconciles — a reviewed plan confirms Terraform stops recreating it and shows only understood changes.

💡 The original post has an interactive diagram of this flow — see it here.

Drift and an actual conflict are not the same

These errors share symptoms, not treatment.

Situation	What happened	Safe response
Existing resource outside state	The object was created outside Terraform, migrated, or lost from the backend	Confirm the configuration should own it, then import it
Drift	A managed resource changed outside configuration	Compare state, configuration, and remote; reconcile through the plan or update code
Actual conflict	Configuration tries to manage an object owned by another module, state, or team	Establish one owner; do not import blindly
Wrong address	A `for_each`, `count`, module, or name changed	Move or import to the correct address after reviewing the plan

The important detail: drift does not automatically mean the object is absent from state. It may be a changed property on a resource Terraform already knows. A create failure, on the other hand, often signals an ownership gap: the provider has the object and the Terraform address does not.

There may also be more than one state managing the same thing. Importing the object into both does not fix that; it duplicates the dispute. First decide which configuration owns it and which one only reads it through data sources or remote outputs.

A safe diagnostic flow

Do not run import on instinct. Follow a short, reversible sequence.

1. Freeze concurrent changes

While investigating, avoid parallel apply operations over the same scope. You do not need to delete, recreate, or edit the remote object to diagnose this. The priority is preventing state and provider changes from happening at the same time.

2. Read the error as a clue, not an instruction

Identify the address Terraform tried to create and the object type. Then check whether it is already recorded:

terraform state list | grep 'aws_example_binding.app'
terraform state show 'aws_example_binding.app["blue"]'

If it is absent from state list, that only confirms a local absence: you still need to establish whether the remote resource belongs at that address. If it is present, compare its attributes with configuration and with the provider API or console in read-only mode.

3. Confirm configuration intent

Review the Terraform block that declares the resource. Ask:

Should this resource exist once, or once for every for_each key?
Did the module, key, or index change recently?
Does another state already have an address describing the same object?
Does current configuration represent how the existing object should end up?

Do not import an object just to make a pipeline green if configuration would replace it, associate it with the wrong target, or duplicate it in the next plan.

4. Inspect the remote using synthetic identifiers

Use a read-only provider query to confirm identity and critical properties. For example, using a synthetic resource ID:

cloudctl example describe --id example-1234567890

The exact command depends on the provider. What matters is a verifiable match between the remote object, the Terraform address, and the identifier accepted by terraform import.

Import declares ownership; it does not repair infrastructure

When configuration should manage the existing object and no other state owns it, import is the smallest change. Import changes state; it does not create, delete, or update the remote resource.

Example with a deliberately synthetic address and identifier:

terraform import \
  'aws_example_binding.app["blue"]' \
  'example-1234567890'

Many compound resources use an import ID made from several fields. Check the resource-type documentation and use only values from the environment where Terraform runs. Never copy identifiers across accounts, environments, or backends.

After import, the work has only started. Create and read a saved plan in full:

terraform plan -out=recovery.tfplan
terraform show recovery.tfplan

The expected result is not always "no changes." An in-place update may appear because the remote resource reflects an earlier manual decision while configuration defines the desired state. That can be correct, but only when every change is understood and acceptable.

Stop if the plan proposes to destroy, replace, or modify objects outside the recovery scope. A successful import proves only that Terraform can read the object; it does not prove the code is safe to apply.

Cases that need a different tool

Not everything is an import.

Address changes with no remote change: if the resource is already in the same state but its module or key changed, a moved block is more precise than importing it again.
An object that should no longer be managed: terraform state rm removes state ownership, not the remote object. Use it only after explicitly deciding who will manage the object.
A shared resource: model it as a data source or expose values from the owning state. Two configurations should not compete for the same lifecycle.
A resource incompatible with configuration: fix configuration before importing. State cannot make an incorrect intent safe.

In production, deleting and recreating to resolve a conflict is particularly risky: it can change addresses, dependencies, data, permissions, or connectivity. State recovery exists to avoid that risk.

Rollback and verification

Before changing state, make sure a recoverable copy exists through the backend and your team's approved operating process. If the import targeted the wrong address, the usual rollback is restoring state from that copy or removing only that ownership entry after reviewing the correct address. Do not treat rollback as permission to alter the remote resource.

The minimum verification looks like this:

terraform state show displays the object at the expected address.
terraform plan no longer attempts to create it.
Every remaining planned change has a specific explanation.
No other state is trying to manage the same object.
apply runs from the reviewed plan with state locking enabled.

Once the plan is predictable again, this stops being a creation error and becomes what Terraform does best: reconciling declared intent with existing infrastructure.

Conclusion

Resource Already Exists is not an invitation to destroy infrastructure. It is an ownership alarm. Separate drift from a real conflict, verify who should own the object, import only when configuration is the correct owner, and review the plan before applying it.

Originally published on DevEdge Blog.

Despliegues Angular multi-tenant: CloudFront vs Cloudflare Pages

Darell Estren — Tue, 25 Aug 2026 20:16:34 +0000

La decisión no es CloudFront contra Cloudflare Pages

La decisión real es qué debe aislarse por tenant. Un mismo build de Angular puede atender varios hostnames si el edge identifica el host y la aplicación recibe un contexto de tenant. También puedes publicar un build por tenant, con su propio proyecto, dominio y versión. Ambas opciones pueden ser correctas; resuelven límites operativos distintos.

Build compartido: una liberación, un artefacto y routing por hostname en el edge.
Despliegue independiente: un artefacto y una liberación por tenant.

Build compartido:
  escuela.example.test ─┐
                         ├─> edge: identifica el host ─> build compartido
  clinica.example.test ─┘

Despliegues independientes:
  escuela.example.test ─> app Angular (despliegue por tenant)
  clinica.example.test ─> app Angular (despliegue por tenant)

💡 El post original tiene un diagrama interactivo de ambos modelos — míralo aquí.

Compara el límite que importa

Criterio	Build compartido con routing por host	Despliegue independiente por tenant
Aislamiento de tenants	Debe estar en autenticación, autorización, datos y configuración de backend; el bundle no es una frontera de seguridad.	Añade separación de artefactos y releases, pero no reemplaza autorización ni controles de datos.
Routing	El CDN o una función edge resuelve `escuela.example.test` y entrega el mismo frontend con contexto de tenant.	Cada hostname se asocia a su propia publicación; el frontend puede incorporar configuración específica.
Independencia de releases	Baja: una versión compartida alcanza a todos.	Alta: puedes publicar, pausar o revertir un tenant sin cambiar los demás.
Caché y dominios	Una política común simplifica la plataforma; requiere disciplina para no mezclar contenido o respuestas por host.	Las políticas y los dominios se administran por tenant; hay más superficies que revisar.
Operación	Menos pipelines, artefactos y puntos de despliegue.	Más proyectos o distribuciones, configuraciones, verificaciones y automatización.

No conviertas esta tabla en una promesa de aislamiento automático. Por ejemplo, un build independiente no impide que una API devuelva datos de otro tenant si el servidor acepta un identificador sin validar la identidad. El límite de seguridad debe estar donde se autoriza la solicitud y se filtran los datos.

Modelo 1: un build Angular, varios hostnames

Este modelo encaja cuando los tenants comparten producto, código y calendario de cambios. El edge recibe un hostname, por ejemplo escuela.example.test, y enruta la solicitud hacia el mismo artefacto estático. Angular puede leer un contexto de configuración al iniciar; el backend sigue siendo responsable de validar el tenant y el usuario en cada llamada.

El diseño es pequeño, pero necesita reglas claras:

No confíes solo en el hostname enviado por el navegador. El backend debe derivar o validar el tenant contra identidad, dominio permitido y permisos.
Separa contenido que depende del tenant. Si una respuesta de API, HTML generado o redirección varía por host, la clave de caché y los encabezados deben respetar esa variación.
Mantén el shell de Angular actualizable. index.html y los manifiestos del service worker suelen requerir una política distinta de los recursos con hash. Así la aplicación puede descubrir una nueva versión sin dejar obsoleta la página inicial.
Prueba rutas profundas. El CDN necesita servir el punto de entrada de la SPA para rutas de Angular Router; de otro modo, una recarga en una URL interna puede devolver un 404.

CloudFront suele modelar este patrón con orígenes, comportamientos de caché, funciones edge y dominios asociados a una distribución. No necesitas una función edge si el origen y el contenido son idénticos para todos los hostnames, pero sí necesitas decidir dónde se obtiene y valida el contexto de tenant.

Modelo 2: un despliegue por tenant

Un proyecto de Cloudflare Pages —o una distribución y un origen separados— por tenant sirve cuando el artefacto debe cambiar de forma independiente: una configuración de compilación, una integración, una ventana de mantenimiento o un rollback aislado.

La ventaja principal es de entrega, no de seguridad. Puedes mantener escuela.example.test en una publicación mientras clinica.example.test recibe otra. El costo es operativo: cada tenant necesita configuración reproducible de build, dominio, caché, fallback de SPA y verificación posterior al despliegue.

En Cloudflare Pages, el fallback de SPA y los encabezados de caché se pueden declarar como archivos estáticos del build. Evita reglas de encabezados superpuestas cuando el proveedor combina valores en lugar de reemplazarlos: una regla precisa por ruta es más fácil de verificar. Los dominios personalizados también deben comprobarse contra el proyecto correcto; una página que responde correctamente puede seguir sirviendo el build de otro tenant si el dominio apunta a la publicación equivocada.

Cómo elegir sin diseñar de más

Elige build compartido si todos los tenants pueden aceptar la misma versión al mismo tiempo y la diferencia real está en datos, permisos y configuración validada por el servidor. Es el modelo con menos artefactos y menos pasos repetidos.

Elige despliegues independientes si necesitas cualquiera de estas garantías operativas:

liberar, revertir o congelar un tenant sin afectar a los demás;
compilar configuraciones que no deben convivir en el mismo artefacto;
validar dominios, integración o comportamiento de caché por tenant antes de publicar;
delegar la operación de una publicación concreta sin entregar el control de toda la plataforma.

Puedes empezar con el build compartido y separar solo los tenants que demuestren una necesidad de independencia. Hacer lo contrario crea una matriz de pipelines y dominios antes de saber si alguien necesita usarla.

Checklist de release

Antes de publicar cualquiera de los dos modelos, verifica:

[ ] El backend autoriza al usuario y el tenant; el hostname no es la única prueba.
[ ] Las rutas internas de Angular sobreviven una recarga.
[ ] index.html y los archivos de actualización no quedan atrapados en una caché larga.
[ ] Los recursos con hash pueden reutilizar caché sin ocultar una versión nueva del shell.
[ ] Cada dominio personalizado entrega el artefacto esperado.
[ ] El rollback tiene un artefacto o publicación identificable y una verificación posterior.

Conclusión

CloudFront y Cloudflare Pages son mecanismos de entrega; el modelo multi-tenant define el límite que operas. Comparte el build cuando compartes releases y separa despliegues cuando necesitas independencia real de publicación. En ambos casos, deja el aislamiento de datos y autorización en el backend, donde puede verificarse en cada solicitud.

Publicado originalmente en DevEdge Blog.

Bugs de caché en Angular al cambiar de contexto de usuario

Darell Estren — Tue, 25 Aug 2026 20:16:33 +0000

El bug: la API respondió bien, pero el usuario vio datos ajenos a su contexto

Una caché suele fallar después de cambiar de usuario, tenant, cuenta activa o permiso. La pantalla solicita el mismo endpoint y la caché responde rápido; el problema es que esa respuesta pertenece al contexto anterior.

La causa no es Angular ni HttpClient. Es una clave que no representa el resultado. Si la respuesta depende de contextId, una clave basada solo en la URL afirma erróneamente que ambas solicitudes son equivalentes.

	Clave incompleta (`GET /api/summary`)	Clave compuesta (`summary:{contextId}`)
Contexto A	`GET /api/summary` → response A	`summary:context-a` → response A
Contexto B	`GET /api/summary` → HIT: reutiliza la respuesta de A — dato obsoleto	`summary:context-b` → response B

💡 El post original tiene una demo interactiva de esta comparación — pruébala aquí.

La regla es sencilla: la clave debe incluir cada input que pueda cambiar la respuesta. Normalmente incluye ruta, parámetros normalizados, usuario o tenant actual, idioma, permisos relevantes y versión de datos cuando aplique. No agregues valores decorativos: solo dependencias reales del resultado.

Un servicio pequeño con clave compuesta

Este ejemplo mantiene la caché en memoria. El servicio que conoce el cambio de contexto la invalida explícitamente; no deja que una entrada vieja sobreviva por casualidad.

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable, shareReplay } from 'rxjs';

interface Summary {
  total: number;
}

@Injectable({ providedIn: 'root' })
export class SummaryCache {
  private contextId = '';
  private readonly entries = new Map<string, Observable<Summary>>();

  constructor(private readonly http: HttpClient) {}

  setContext(contextId: string): void {
    if (contextId === this.contextId) return;
    this.contextId = contextId;
    this.entries.clear();
  }

  getSummary(filter: string): Observable<Summary> {
    const normalizedFilter = filter.trim().toLowerCase();
    const key = `summary:${this.contextId}:${normalizedFilter}`;
    const cached = this.entries.get(key);

    if (cached) return cached;

    const request = this.http
      .get<Summary>('/api/summary', { params: { filter: normalizedFilter } })
      .pipe(shareReplay({ bufferSize: 1, refCount: true }));

    this.entries.set(key, request);
    return request;
  }
}

El detalle importante no es el Map; es la identidad. Dos contextos o filtros distintos producen claves distintas. setContext borra las entradas cuando la fuente de identidad cambia, lo que también evita conservar datos sensibles más tiempo del necesario.

Si el cambio de usuario crea una aplicación completamente nueva, una caché en memoria puede desaparecer sola. No dependas de ese efecto: el problema reaparece con un selector de tenant, una impersonación administrativa, un cambio de permisos o una caché persistente.

Diagnóstico seguro

Empieza sin exponer datos reales.

Reproduce con dos contextos de prueba y respuestas sintéticas distinguibles, como response A y response B.
Registra o inspecciona solo la forma de la clave: ruta, filtros normalizados y un identificador sintético de contexto.
Cambia de contexto sin recargar la aplicación y confirma si la segunda solicitud obtiene un HIT para una clave que no contiene el contexto.
Revisa todos los lugares que leen y limpian la caché. Corregir solo un componente deja rutas hermanas vulnerables.

Evita registrar cuerpos de respuestas, tokens o identificadores reales. Para este diagnóstico basta demostrar que dos resultados distintos están usando la misma clave.

Pruebas que detectan la regresión

La prueba mínima verifica identidad e invalidación, no la implementación interna de Map. Cada prueba crea su propia caché y cliente HTTP falso, así que puede ejecutarse de forma aislada.

it('does not reuse a summary after the context changes', () => {
  const { cache, fakeHttp } = createSummaryCacheWithFakeHttp();

  cache.setContext('context-a');
  cache.getSummary('open').subscribe();

  cache.setContext('context-b');
  cache.getSummary('open').subscribe();

  expect(fakeHttp.urls).toEqual(['/api/summary', '/api/summary']);
});

it('reuses the same request inside one context', () => {
  const { cache, fakeHttp } = createSummaryCacheWithFakeHttp();

  cache.setContext('context-a');
  cache.getSummary('open').subscribe();
  cache.getSummary(' OPEN ').subscribe();

  expect(fakeHttp.urls).toHaveLength(1);
});

Añade un caso por cada dimensión que altere la respuesta: tenant, idioma, filtro, rol o versión. Si una dimensión no aparece en la clave, la prueba debe demostrar que no cambia el resultado; de lo contrario, inclúyela.

Errores frecuentes

Error	Por qué falla	Corrección mínima
Usar solo la URL	Dos contextos comparten una entrada	Añadir identidad de contexto a la clave
Limpiar solo al cerrar sesión	Un cambio de tenant o permisos mantiene datos anteriores	Invalidar en toda transición de contexto
Usar objetos sin normalizar como clave	El orden o el espaciado crean entradas duplicadas	Normalizar valores antes de formar la clave
Guardar una caché global sin alcance	Una pantalla comparte datos con otra	Mantener la caché cerca de su dominio de datos
Confiar solo en TTL	Durante el TTL el dato equivocado sigue siendo posible	Invalidar de forma explícita al cambiar contexto

Un TTL controla antigüedad; no corrige identidad. La clave evita que un dato incorrecto entre; la invalidación elimina datos que dejaron de ser válidos.

Lista de verificación

[ ] La clave contiene todos los inputs que cambian el resultado.
[ ] Los valores se normalizan antes de crear la clave.
[ ] Cada transición de usuario, tenant, permiso o cuenta invalida el dominio afectado.
[ ] Las pruebas cubren un HIT dentro del mismo contexto y un MISS entre contextos.
[ ] Los logs de diagnóstico usan valores sintéticos y no incluyen respuestas ni credenciales.

Publicado originalmente en DevEdge Blog.

Terraform dice que el recurso ya existe: recupera la propiedad del state

Darell Estren — Tue, 25 Aug 2026 20:13:00 +0000

El problema no es que Terraform no pueda crear el recurso

Un AlreadyExists, AlreadyAssociated o conflicto de creación suele disparar la reacción equivocada: borrar algo y volver a ejecutar apply. No lo hagas. Terraform no está diciendo que la infraestructura esté necesariamente mal; está diciendo que intenta crear algo que el proveedor ya conoce, mientras su state no lo considera bajo su propiedad.

La pregunta correcta no es “¿cómo lo elimino?”, sino: ¿qué objeto real existe, quién debería administrarlo y qué representa hoy el state?

Terraform trabaja con dos fuentes de verdad: la configuración define el estado deseado y el state registra qué objetos remotos administra cada dirección de recurso. Si un objeto existe pero falta esa relación en el state, Terraform planea un create. El proveedor rechaza la creación porque el objeto —o una relación exclusiva, como una asociación— ya existe.

En resumen, el ciclo de recuperación tiene cuatro pasos:

El recurso remoto existe — el proveedor ya conoce el objeto, aunque Terraform todavía no lo administra desde esta dirección.
Terraform planea crearlo — al no encontrar ownership en el state, la configuración propone un create que el proveedor rechaza.
El import establece ownership — importar vincula el objeto existente con la dirección correcta en el state sin modificar el recurso remoto.
El plan revisado reconcilia — un plan revisado confirma que Terraform deja de recrearlo y muestra solo los cambios entendidos.

💡 El post original tiene un diagrama interactivo de este flujo — mirálo acá.

Drift y conflicto real no son lo mismo

Estos errores comparten síntomas, pero no tratamiento.

Situación	Qué ocurrió	Respuesta segura
Recurso existente fuera del state	El objeto fue creado fuera de Terraform, migrado o se perdió del backend	Confirmar que la configuración debe poseerlo e importarlo
Drift	Un recurso ya administrado cambió fuera de la configuración	Comparar state, configuración y remoto; dejar que el plan reconcilie o ajustar código
Conflicto real	La configuración intenta administrar un objeto que pertenece a otro módulo, state o equipo	Definir un único dueño; no importar a ciegas
Dirección equivocada	Un `for_each`, `count`, módulo o nombre cambió	Mover o importar hacia la dirección correcta, después de revisar el plan

El detalle importante: drift no significa automáticamente que el objeto falte del state. Puede ser una propiedad diferente en un recurso que Terraform sí conoce. En cambio, un error al crear normalmente señala una brecha de ownership: el proveedor tiene el objeto y la dirección de Terraform no.

También puede haber más de un state gestionando la misma cosa. Importar el mismo objeto en ambos no arregla nada; duplica la disputa. Primero decide cuál configuración será la propietaria y cuál solo la consulta mediante data sources o salidas remotas.

Flujo de diagnóstico seguro

No ejecutes import por intuición. Seguí una secuencia corta y reversible.

1. Congelá cambios concurrentes

Mientras investigas, evita apply paralelos sobre el mismo alcance. No necesitas borrar, recrear ni editar el objeto remoto para diagnosticar. La prioridad es que nadie cambie state y proveedor al mismo tiempo.

2. Leé el error como una pista, no como una instrucción

Identificá la dirección que Terraform intentó crear y el tipo de objeto. Luego buscá si ya está registrado:

terraform state list | grep 'aws_example_binding.app'
terraform state show 'aws_example_binding.app["blue"]'

Si no aparece en state list, eso confirma solo una ausencia local: todavía falta saber si el recurso remoto corresponde a esa dirección. Si aparece, compara sus atributos con la configuración y con la API o consola del proveedor en modo lectura.

3. Confirmá la intención de la configuración

Revisá el bloque Terraform que declara el recurso. Preguntá:

¿Ese recurso debe existir una sola vez o por cada clave de for_each?
¿El módulo, la clave o el índice cambiaron recientemente?
¿Otro state ya tiene una dirección que describe el mismo objeto?
¿La configuración actual representa el objeto existente tal como debería quedar?

No importes un objeto para “hacer verde el pipeline” si la configuración lo reemplazaría, lo asociaría a un destino incorrecto o lo duplicaría en el siguiente plan.

4. Inspeccioná el remoto con identificadores sintéticos

Usá una consulta de sólo lectura del proveedor para confirmar identidad y propiedades críticas. Por ejemplo, para un recurso con ID sintético:

cloudctl example describe --id example-1234567890

El comando exacto depende del proveedor. Lo importante es registrar una correspondencia verificable entre el objeto remoto, la dirección Terraform y el identificador que acepta terraform import.

Importar es declarar ownership, no reparar infraestructura

Cuando la configuración debe administrar el objeto existente y ningún otro state lo posee, importarlo es el cambio mínimo. El import modifica el state; no crea, borra ni actualiza el recurso remoto.

Ejemplo con una dirección y un identificador deliberadamente sintéticos:

terraform import \
  'aws_example_binding.app["blue"]' \
  'example-1234567890'

Para muchos recursos compuestos, el import ID combina campos. Consulta la documentación del tipo de recurso y usa solo los valores del entorno donde ejecutas Terraform. No copies identificadores entre cuentas, entornos o backends.

Después del import, el trabajo recién empieza. Ejecutá un plan guardado y leelo completo:

terraform plan -out=recovery.tfplan
terraform show recovery.tfplan

El resultado esperado no siempre es “sin cambios”. Puede haber una actualización in-place porque el recurso remoto refleja una decisión manual anterior y la configuración define el estado deseado. Eso puede ser correcto, pero sólo si cada cambio es entendido y aceptable.

Detenete si el plan propone destruir, reemplazar o modificar objetos fuera del alcance de la recuperación. Un import exitoso sólo prueba que Terraform puede leer el objeto; no prueba que el código sea seguro para aplicarlo.

Casos que requieren otra herramienta

No todo se resuelve con import.

Cambio de dirección sin cambio remoto: si el recurso ya está en el mismo state pero cambió de módulo o clave, un bloque moved es más preciso que importar otra vez.
Objeto que debe dejar de ser administrado: terraform state rm elimina ownership del state, no el objeto remoto. Es útil sólo después de decidir explícitamente quién lo administrará.
Recurso compartido: modélalo como data source o expón sus valores desde el state dueño. Dos configuraciones no deberían competir por el mismo ciclo de vida.
Recurso no compatible con la configuración: corrige la configuración antes de importar. El state no convierte una intención incorrecta en una segura.

En producción, borrar y recrear para resolver un conflicto es especialmente peligroso: puede cambiar direcciones, dependencias, datos, permisos o conectividad. La recuperación de state busca precisamente evitar ese riesgo.

Rollback y verificación

Antes de cambiar state, asegura una copia recuperable mediante el backend y el mecanismo operativo aprobado por tu equipo. Si el import fue hacia una dirección equivocada, el rollback habitual es restaurar el state desde esa copia o eliminar solo esa entrada de ownership después de revisar la dirección correcta. No uses el rollback como permiso para tocar el recurso remoto.

La verificación mínima queda así:

terraform state show muestra el objeto en la dirección esperada.
terraform plan no intenta crearlo de nuevo.
Cada cambio restante del plan tiene una explicación concreta.
No existe otro state intentando administrar el mismo objeto.
El apply se ejecuta con el plan revisado y el bloqueo de state activo.

Cuando el plan vuelve a ser predecible, el incidente deja de ser un error de creación y vuelve a ser lo que Terraform hace mejor: reconciliar una intención declarada con infraestructura existente.

Conclusión

Resource Already Exists no es una invitación a destruir infraestructura. Es una alarma sobre ownership. Separa drift de conflicto real, verifica quién debe poseer el objeto, importa solo cuando la configuración sea la dueña correcta y revisa el plan antes de aplicar.

Publicado originalmente en DevEdge Blog.