🚀 Enhancements
fix(pro): respect metadata.enabled when uploading instances for drift @osterman (#2563)
## whatatmos list instances --uploadnow collapses the Atmos Pro enabled hierarchy (metadata.enabled>settings.pro.enabled>settings.pro.drift_detection.enabled) before uploading, so the values Atmos Pro persists already reflect any outer disable.- A shared
effectiveEnabledStatehelper is the single source of truth for both the upload payload (extractProSettings) and the success-toast counts, so they can no longer diverge. - Disabled components are still uploaded (as
pro.enabled: false) rather than omitted, so Atmos Pro shows them disabled instead of orphaning them. - Reference docs corrected (
settings/pro.mdxgains asettings.pro.enabledentry + precedence note;list/list-instances.mdxdrops the now-false "preserved verbatim" / "drift is independent of pro.enabled" claims), plus adocs/fixes/write-up.
why
- Components disabled upstream via
metadata.enabled: falsekept failing scheduled drift detection (dispatchError: "missing_plan_result",drift_status: error): the CLI skips planning them, but the upload serialized the rawsettings.problock and never sentmetadata.enabled, so Atmos Pro (whose ingestion contract has nometadatafield) persisted them asenabled:true, drift_enabled:trueand legitimately dispatched drift. - Fixing it in the CLI keeps the determination where it is already resolved and needs no Atmos Pro change: the stuck
errorrows self-heal todisabledon the next upload, with no data migration. pro.enableddefaults totrue(matching the Pro server-side default) so the collapse only ever turns things off when an outer level is explicitly disabled — it never regresses default-enabled components.
references
docs/fixes/2026-06-03-drift-dispatch-ignores-metadata-enabled.md(root-cause analysis, Neoninstancesevidence, verification steps)- Source of truth for the disabled determination:
internal/exec/component_utils.go(isComponentEnabled)
Summary by CodeRabbit
-
Bug Fixes
- Resolve upload so component enablement honors metadata.enabled, preventing metadata-disabled components from remaining scheduled for drift and correcting counts; disabled components are uploaded as disabled rather than omitted.
-
Documentation
- Clarify enablement precedence (metadata.enabled > settings.pro.enabled > drift_detection.enabled), upload behavior, and how effective Pro/drift state is reflected in UI counts.
-
Tests
- Add unit and end-to-end tests validating effective enablement resolution, drift counting, and uploaded payloads.
fix(auth): deduplicate ECR, ECR Public, and EKS integrations to once per process @MrZablah (#2564)
## WhatAdds a process-level execution cache to triggerIntegrations so that
auto-provisioned integrations (aws/ecr, aws/ecr-public, aws/eks)
fire at most once per atmos invocation, regardless of how many times
Authenticate is called or how many AuthManager instances are created.
The cache key is the integration's canonical target endpoint rather than
its config entry name:
aws/ecr→"aws/ecr:<account_id>:<region>"aws/ecr-public→"aws/ecr-public"(single global registry)aws/eks→"aws/eks:<cluster_name>:<region>"- everything else → integration name (no behaviour change)
This means two config entries that point at the same registry — e.g. one
from global atmos.yaml and one from a component stack file — are
collapsed to a single execution.
Why
atmos terraform plan calls Authenticate from at least three internal
paths: setupTerraformAuth, TerraformPreHook, and one call per YAML
function (!store.get, !terraform.state). With a 6-tool .tool-versions
this produced 6 ECR logins per command. Switching to a name-keyed cache
reduced it to 2 because merged configs can carry two integration entries
with different names for the same registry. Keying by target endpoint
reduces this to exactly 1.
Changes
pkg/auth/manager_integrations.go— addsprocessIntegrationCache sync.Map,resetProcessIntegrationCache()(test helper),
integrationTargetKey()(canonical key helper coveringaws/ecr,
aws/ecr-public,aws/eks); updatestriggerIntegrationsto use
LoadOrStoreon the target key.pkg/auth/manager_integrations_test.go— adds
TestIntegrationTargetKey(table-driven tests for all key variants
including ECR Public) andTestIntegrationTargetKey_Deduplication
(verifies that two same-registry entries produce one cache hit).
Notes
aws/ecr-public was added to upstream/main in #2231 after this branch
diverged; coverage for it was added here to keep deduplication consistent
across all three AWS integration kinds.
references
ECR / ECR Public Login Executes Multiple Times Per atmos terraform Invocation
#2562
Summary by CodeRabbit
-
New Features
- Added process-level deduplication for auto-provisioned integrations to prevent redundant provisioning of the same target within a single process.
- Failed provisioning attempts are evicted from the dedupe cache so retries can proceed.
-
Tests
- Added unit tests validating cache key behavior and deduplication scenarios to ensure consistent provisioning outcomes.