Simplify sensitive argument checking by merging redundant layers

[coderabbitai]

Problem

Sensitive-argument checking in the runner module uses two layers (contains_sensitive_keyword and is_sensitive_arg) which creates redundant wrappers.

Proposed Solution

Merge these into a single, more direct predicate to:

• Avoid redundant wrappers
• Simplify the logic
• Reduce complexity

Context

• Identified during code review in PR Clean workflow cache before build #69
• Comment: Clean workflow cache before build #69 (comment)
• Issue: Simplify sensitive argument checking by merging redundant layers #77

[leynos]

@coderabbitai looking at the codebase, is this issue still relevant? If the issue has been fixed in the code, does the documentation reflect this?

If it is still relevant, please provide an assessment of the issue criticality (critical, high, medium or low), based on risk of the issue impacting the user and the anticipated blast radius.

Once a decision has been made, apply the appropriate label.

If the issue is documentation ONLY (i.e., no code changes needed), apply the documentation label in addition to the appropriate criticality label.

Please also provide an impact of the required changes.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, let's find the runner module and examine sensitive argument checking
echo "=== Looking for runner module ==="
fd -t f -e py runner

echo -e "\n=== Searching for sensitive argument functions ==="
rg -n "contains_sensitive_keyword|is_sensitive_arg" --type py

echo -e "\n=== Looking for sensitive argument checking logic in runner files ==="
fd -t f -e py runner --exec cat {}

Length of output: 623

---

🏁 Script executed:

#!/bin/bash
# Let's explore the codebase structure first
echo "=== Codebase structure ==="
find . -name "*.py" | head -20

echo -e "\n=== Searching for any sensitive-related code ==="
rg -n "sensitive" --type py -C2

echo -e "\n=== Searching for runner-related code more broadly ==="
rg -n "runner" --type py -C2

echo -e "\n=== Looking for the specific functions mentioned in the issue ==="
rg -n "contains_sensitive_keyword" . || echo "No matches for contains_sensitive_keyword"
rg -n "is_sensitive_arg" . || echo "No matches for is_sensitive_arg"

Length of output: 2021

---

🏁 Script executed:

#!/bin/bash
# Let's examine the runner.rs file to understand the current implementation
echo "=== Full runner.rs content ==="
cat src/runner.rs

echo -e "\n=== Let's also check if there are any other files that might be relevant ==="
find . -name "*.rs" | head -10

Length of output: 14695

---

@leynos, I've analyzed the codebase and the issue is still relevant. The redundant layers described in issue #77 continue to exist in the current code.

Current State Analysis

In src/runner.rs, I found the exact redundancy mentioned:

1. contains_sensitive_keyword(arg) (lines 297-299): Contains the actual logic to check for sensitive keywords ("password", "token", "secret")
2. is_sensitive_arg(arg) (lines 310-312): Simply calls contains_sensitive_keyword(arg) with no additional logic

pub(crate) fn is_sensitive_arg(arg: &CommandArg) -> bool {
    contains_sensitive_keyword(arg)  // Direct pass-through, adds no value
}

Criticality Assessment: Low

• Risk to users: None - this is purely internal code quality
• Blast radius: Minimal - affects only internal sensitive argument checking logic
• Impact: Code maintainability and clarity

Impact of Required Changes

Minimal impact, straightforward refactoring:

• Remove the is_sensitive_arg wrapper function
• Replace the single usage in redact_argument() (line 327) to call contains_sensitive_keyword directly
• Update any doctests that reference the removed function
• No API changes or functional behavior modifications

The change would eliminate redundant code while maintaining identical functionality, improving code clarity and reducing maintenance overhead.

---

🏁 Script executed:

#!/bin/bash
# Apply the "low" criticality label to the issue
gh issue edit 77 --add-label "low"

echo "=== Applied 'low' criticality label to issue #77 ==="

Length of output: 199

---

Perfect! I've successfully applied the "low" criticality label to issue #77. The analysis confirms this is a straightforward code quality improvement that can be addressed through simple refactoring with minimal risk and impact.