detect cycle in cli custom commands

[pkbhowmick]

what

why

references

• DEV-2688

Summary by CodeRabbit

• New Features

  • Introduced a cycle detection mechanism for custom CLI commands to prevent command dependency cycles.

• Bug Fixes

  • Enhanced error handling for command processing by validating command dependencies before execution.

• Documentation

  • Updated comments to clarify the purpose and functionality of the new cycle detection logic.

[osterman]

This is not wrong, but we still need to catch when atmos is executing atmos in a free form command. Walking the tree won't help with that.

The only practical way is to set an environment variable for the sub command and increment it. We should allow some level of recursion, just not infinite.

[coderabbitai]

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

Walkthrough

The changes introduce a cycle detection mechanism for custom CLI commands in the cmd/cmd_utils.go file. A new function, detectCycle, is implemented to construct a command dependency graph and identify cycles using depth-first search (DFS). The processCustomCommands function is updated to call detectCycle, ensuring that command processing halts if a cycle is detected. Additionally, comments have been updated for clarity regarding the new functionality.

Changes

File	Change Summary
cmd/cmd_utils.go	- Added detectCycle(commands []schema.Command) bool for cycle detection.
	- Added detectCycleUtil(command string, graph map[string][]string, visited, recStack map[string]bool) bool for DFS cycle detection.
	- Added parseCommandName(step string) string to extract command names.
	- Modified processCustomCommands to incorporate cycle detection and return an error if a cycle is found.
	- Updated comments for clarity on new cycle detection logic.

Assessment against linked issues

Objective	Addressed	Explanation
Detect cycles in Atmos commands to prevent recursive calls (DEV-2688)	✅

Possibly related issues

• DEV-2688: The changes directly address the need to detect cycles in Atmos commands, aligning with the objectives outlined in the issue.

Possibly related PRs

• improve custom command error message for missing arguments #752: This PR enhances error handling in cmd/cmd_utils.go, which is relevant to the command management context addressed in the main PR.

Suggested labels

minor

Suggested reviewers

• osterman
• johncblandii
• gberenice
• aknysh

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary or @auto-summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai or @auto-title anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 3

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 4098092 and 91ad5e6.

📒 Files selected for processing (1)

• cmd/cmd_utils.go (2 hunks)

[pkbhowmick]

This is not wrong, but we still need to catch when atmos is executing atmos in a free form command. Walking the tree won't help with that.

The only practical way is to set an environment variable for the sub command and increment it. We should allow some level of recursion, just not infinite.

Thanks for the info @osterman . I'll change accordingly

[pkbhowmick]

This is not wrong, but we still need to catch when atmos is executing atmos in a free form command. Walking the tree won't help with that.

The only practical way is to set an environment variable for the sub command and increment it. We should allow some level of recursion, just not infinite.

Hi @osterman
if there is a cycle then the recursion will never end. i.e. do you want to allow cycle for some iteration?

[osterman]

This is not wrong, but we still need to catch when atmos is executing atmos in a free form command. Walking the tree won't help with that.
The only practical way is to set an environment variable for the sub command and increment it. We should allow some level of recursion, just not infinite.

Hi @osterman if there is a cycle then the recursion will never end. i.e. do you want to allow cycle for some iteration?

Only if we know conclusively, without a doubt, that it will result in infinite recursion. The problem I foresee is it we cannot easily determine anything conclusively.

That is my way of saying, we probably need to allow for some recursion before triggering the circuit breaker.

[pkbhowmick]

[pkbhowmick]

I might be wrong but I have found that from code the command is run once. When there is a cycle and the command reaches to shell. Shell automatically runs that cyclic command. I have found no way to control it from code.

That's why I am proposing a way to let the user know about the cycle and run/exit command based on user input.

cc: @osterman

[osterman]

I might be wrong but I have found that from code the command is run once. When there is a cycle and the command reaches to shell. Shell automatically runs that cyclic command. I have found no way to control it from code.

Please provide more technical details. This is conventional behavior of task runner functionality, and not something novel we are attempting to implement.

[osterman]

As far as I can tell, this implementation never sets an environment variable, and that environment variable, therefore never passed to the recursive shell. Therefore, there is no circuit breaker. This is attempting strictly to implement a circuit breaker using the YAML definition, which is going be very complicated please implement the circuit breaker using an environment variable

[osterman]

It is similar in principle to what we have going on in this other Pool request to send the Shell level. The difference is that at a certain depth we should fatally exit.

• increment ATMOS_SHLVL each time atmos terraform shell is called #803

[pkbhowmick]

I might be wrong but I have found that from code the command is run once. When there is a cycle and the command reaches to shell. Shell automatically runs that cyclic command. I have found no way to control it from code.

Please provide more technical details. This is conventional behavior of task runner functionality, and not something novel we are attempting to implement.

Hi @osterman
In my finding, when the command runs for the first time, the shell has the full control not the code. But with that env it seems we might have some control. Let me take a look again

[pkbhowmick]

It is similar in principle to what we have going on in this other Pool request to send the Shell level. The difference is that at a certain depth we should fatally exit.

• increment ATMOS_SHLVL each time atmos terraform shell is called #803

While trying this way, I have found we are submitting all the steps to a shell runner. https://github.com/cloudposse/atmos/blob/main/internal/exec/shell_utils.go#L77-L93

Now if we want to control the way of execution of cyclic custom command, we need to do something here. So far I don't find a way

[osterman]

Simply check the ATMOS_SHLVL is not greater than some maximum (e.g. 10). If it is greater log a fatal error. Otherwise, increment the ATMOS_SHLVL envar before execution, and ensure the envar is passed to the command.

If this doesn't work, then submit an example of why not, or there's no feedback that can be given.

[osterman]

Based on the lines you provided, why can't we do something like:

func ExecuteShell(
	cliConfig schema.CliConfiguration,
	command string,
	name string,
	dir string,
	env []string,
	dryRun bool,
) error {
	u.LogDebug(cliConfig, "\nExecuting command:")
	u.LogDebug(cliConfig, command)

	// Retrieve and increment ATMOS_SHLVL
	atmosShlvl := 0
	if value, exists := os.LookupEnv("ATMOS_SHLVL"); exists {
		var err error
		atmosShlvl, err = strconv.Atoi(value)
		if err != nil {
			return fmt.Errorf("invalid ATMOS_SHLVL value: %s", value)
		}
	}
	atmosShlvl++ // Increment ATMOS_SHLVL

	// Check if ATMOS_SHLVL exceeds the limit
	if atmosShlvl > 10 {
		log.Fatalf("Fatal: ATMOS_SHLVL (%d) exceeds the maximum allowed value of 10", atmosShlvl)
		os.Exit(1)
	}

	// Update the environment with the new ATMOS_SHLVL
	newEnv := append(env, fmt.Sprintf("ATMOS_SHLVL=%d", atmosShlvl))

	if dryRun {
		return nil
	}

	// Execute the shell command
	return shellRunner(command, name, dir, newEnv, os.Stdout)
}

[pkbhowmick]

Based on the lines you provided, why can't we do something like:

func ExecuteShell(
	cliConfig schema.CliConfiguration,
	command string,
	name string,
	dir string,
	env []string,
	dryRun bool,
) error {
	u.LogDebug(cliConfig, "\nExecuting command:")
	u.LogDebug(cliConfig, command)

	// Retrieve and increment ATMOS_SHLVL
	atmosShlvl := 0
	if value, exists := os.LookupEnv("ATMOS_SHLVL"); exists {
		var err error
		atmosShlvl, err = strconv.Atoi(value)
		if err != nil {
			return fmt.Errorf("invalid ATMOS_SHLVL value: %s", value)
		}
	}
	atmosShlvl++ // Increment ATMOS_SHLVL

	// Check if ATMOS_SHLVL exceeds the limit
	if atmosShlvl > 10 {
		log.Fatalf("Fatal: ATMOS_SHLVL (%d) exceeds the maximum allowed value of 10", atmosShlvl)
		os.Exit(1)
	}

	// Update the environment with the new ATMOS_SHLVL
	newEnv := append(env, fmt.Sprintf("ATMOS_SHLVL=%d", atmosShlvl))

	if dryRun {
		return nil
	}

	// Execute the shell command
	return shellRunner(command, name, dir, newEnv, os.Stdout)
}

In my testing, I have found this Execute shell command only runs once even for a loop

[osterman]

What we want to catch is atmos calling atmos, infinitely.

It is true that it only runs in once per command, but if that command is literally executing atmos, it will executed recursively. The case I am thinking of right now, is when the type is “shell” and not “atmos”. Start with this and worry about type atmos later.

We want to catch this inside of workflow and custom commands.

The first step would be to add some test cases where we do this, under example/tests. If you add that to this PR, I can review the test case you are using and better understand the behavior you are seeing.

[pkbhowmick]

Here is one example of infinite loop

[osterman]

Yes, that would create an infinite loop!

So in this case, when atmos executes:

atmos hello

It would first increment, and pass ATMOS_SHLVL as an environment variable to the process.

Then when atmos starts, it can check for the presence of ATMOS_SHLVL and if it is set, check that it's not larger than X, or exit with an error.

[osterman]

Checking ATMOS_SHLVL can even happen in the initialization of atmos.