config/dependency.go (2)

122-145: Prefer internal errors package over fmt.Errorf in validators; optionally normalize paths

Use the project's internal errors package to preserve stack traces. Also consider normalizing dependency paths (e.g., via a cleaned/absolute form) to catch semantically identical paths that differ textually ("../vpc" vs "./../vpc").

Apply this diff to switch to the internal errors package:

-			return fmt.Errorf("duplicate config_path '%s' found in dependency blocks. "+
+			return errors.Errorf("duplicate config_path '%s' found in dependency blocks. "+
 				"Dependency '%s' and dependency '%s' both point to the same config path. "+
 				"Each dependency must have a unique config_path",
 				configPath, existingDepName, dep.Name)

Optional follow-up (outside this hunk): if feasible, normalize configPath before comparison (e.g., using a cleaned path relative to the current config) to avoid false negatives when the same path is written differently. I can draft this with minimal API churn if you want to pass a base path into the validator.

---

1219-1229: Filter should also drop empty string config_path values

FilteredWithoutConfigPath currently only removes null cty values. An explicitly empty string slips through and then gets special-cased in ValidateUniqueConfigPaths. Tighten the filter here to exclude empty strings as well, keeping the pipeline consistent and reducing downstream branching.

-	for _, dep := range deps {
-		if !dep.ConfigPath.IsNull() {
-			filteredDeps = append(filteredDeps, dep)
-		}
-	}
+	for _, dep := range deps {
+		if !dep.ConfigPath.IsNull() && dep.ConfigPath.AsString() != "" {
+			filteredDeps = append(filteredDeps, dep)
+		}
+	}

config/hclparse/file.go (1)

139-172: Use all labels for uniqueness and consider nested blocks (optional)

The uniqueness key uses only the first label. For multi-label blocks, this can conflate distinct blocks or miss duplicates. Consider using the full label tuple for the key. Also, this currently checks only top-level blocks; if you intend to enforce uniqueness within nested contexts, recurse into child bodies.

Apply this diff to use the full label tuple for the key:

-		// Check for duplicate block labels (only for blocks with labels)
-		if len(hclBlock.Labels) > 0 {
-			blockKey := hclBlock.Type + "." + hclBlock.Labels[0]
+		// Check for duplicate block labels (only for blocks with labels)
+		if len(hclBlock.Labels) > 0 {
+			labelsKey := strings.Join(hclBlock.Labels, ".")
+			blockKey := hclBlock.Type + "." + labelsKey

And add this import outside the selected hunk:

import "strings"

Optional: If the requirement extends to nested blocks, we can introduce a small DFS over hclsyntax.Block.Body to apply the same uniqueness rule within each scope. I can provide an implementation if you want to expand the coverage.

config/config_partial_test.go (1)

392-446: Tests look good; also ensure the include-path validator uses internal errors package

The test suite correctly exercises duplicate include-path detection. For consistency with project practices (stack traces, etc.), ensure ValidateUniqueIncludePaths (in config/config_partial.go) uses the internal errors package rather than fmt.Errorf, similar to the suggestion for dependency config paths.

Proposed updated implementation (outside this file):

// In config/config_partial.go

import "github.com/gruntwork-io/terragrunt/internal/errors"

func ValidateUniqueIncludePaths(includes IncludeConfigs) error {
    includePaths := make(map[string]string) // map[path]include_name

    for _, inc := range includes {
        if inc.Path == "" {
            // Skip includes without path (shouldn't happen but be defensive)
            continue
        }

        if existingIncludeName, exists := includePaths[inc.Path]; exists {
            return errors.Errorf(
                "duplicate include path '%s' found in include blocks. "+
                    "Include '%s' and include '%s' both point to the same path. "+
                    "Each include must have a unique path",
                inc.Path, existingIncludeName, inc.Name,
            )
        }

        includePaths[inc.Path] = inc.Name
    }

    return nil
}

Optional: as with dependency paths, consider normalizing include paths before comparison to catch semantically identical paths written differently.

config/dependency_test.go (1)

153-189: Optional: add a test covering empty config_path dependencies

ValidateUniqueConfigPaths skips empty config_path values (per implementation). A small positive test with a dependency lacking config_path would harden behavior guarantees.

I can draft a test case if you’d like.

config/config_partial.go (1)

760-781: Consider normalizing include paths before uniqueness check

Current check treats "./parent.hcl" and "parent.hcl" as different. If practical, normalize (filepath.Clean, and optionally make absolute relative to the config dir) to catch semantically identical paths.

If you want to keep the current scope, no action is required for this PR.

config/include.go (1)

651-653: Nit: comment references old function name

Update the comment to reflect the exported MergeDependencyBlocks name.

-// Merge dependency blocks deeply. This works almost the same as mergeDependencyBlocks, except it will recursively merge
+// Merge dependency blocks deeply. This works almost the same as MergeDependencyBlocks, except it will recursively merge
 // attributes of the dependency struct if they share the same name.

docs-starlight/src/content/docs/04-reference/01-hcl/02-blocks.mdx (2)

659-662: Grammar: clarify deprecated bare-include phrasing

Minor wording tweak for readability.

-You can have more than one `include` block, but each one must have a unique label and a unique path. It is recommended to
-always label your `include` blocks. Bare includes (`include` block with no label - e.g., `include {}`) are currently 
-supported for backward compatibility, but is deprecated usage and support may be removed in the future.
+You can have more than one `include` block, but each one must have a unique label and a unique path. It is recommended to
+always label your `include` blocks. Bare includes (`include` block with no label — e.g., `include {}`) are currently
+supported for backward compatibility, but this usage is deprecated and may be removed in the future.

---

1205-1218: Tighten language around dependency labels and config_path uniqueness

Minor style/grammar improvements.

-You can define more than one `dependency` block, but each one must have a unique label and a unique `config_path`.
-Each label you provide to the block identifies another `dependency`
-that you can reference in your config.
+You can define more than one `dependency` block, but each one must have a unique label and a unique `config_path`.
+Each label identifies a dependency that you can reference in your config.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: levkohimins
PR: gruntwork-io/terragrunt#3723
File: cli/commands/stack/action.go:160-160
Timestamp: 2025-02-10T13:36:19.542Z
Learning: The project uses a custom error package `github.com/gruntwork-io/terragrunt/internal/errors` which provides similar functionality to `fmt.Errorf` but includes stack traces. Prefer using this package's error functions (e.g., `errors.Errorf`, `errors.New`) over the standard library's error handling.

Learnt from: Resonance1584
PR: gruntwork-io/terragrunt#4683
File: go.mod:86-90
Timestamp: 2025-08-19T16:05:54.682Z
Learning: When analyzing Go module dependencies for removal, always check for both direct imports and API usage across all Go files in the repository, not just a quick search. The github.com/mattn/go-zglob library is used for filesystem walking and glob expansion in multiple Terragrunt files including util/file.go, format commands, and AWS provider patch functionality.