Python Requirement file choice is cached and reused incorrectly #1034
Description
Describe the bug
Description
tryGetRequirementFile() mutates py.pipRequirementsFile, caching the first successful file choice (setup.py or requirements.txt).
Impact
- Handler reuse across multiple fixes or modules may target the wrong file.
- Confusing behavior in multi-module or multi-vulnerability runs.
Suggested Fix
Avoid mutating shared state; resolve the requirement file independently per fix attempt.
Current behavior
Even if a requirements.txt file is listed, it will still mysteriously fail on not finding a pyproject.toml or setup.py on scan. Furthermore, once the handler successfully reads either setup.py or requirements.txt, it stores that filename in shared state. Subsequent fix attempts reuse that cached file path, even if it is no longer correct for later fixes or modules.
Reproduction steps
Run As Is for Python Code
Expected behavior
Each fix attempt should determine the correct manifest/requirements file for that project context:
- Do not rely on mutable cached state that can leak across fixes/modules.
- If multiple projects are present, selection should be scoped to the relevant project root.
- In short: file resolution should be deterministic and isolated per fix operation.
JFrog Frogbot version
LATEST
Package manager info
PYTHON
Git provider
GitHub
JFrog Frogbot configuration yaml file
DEFAULT
Operating system type and version
ALL
JFrog Xray version
LATEST