How I Found Real Bugs in MoneyPrinterTurbo, CodeceptJS, and Magento — And Got Them Merged

A QA engineer's journey into open source contribution

---

The Problem I Was Trying to Solve

I work as a QA Automation Engineer. Every day I see the same pattern — a developer pushes a commit, QA gets it, and we test... everything. The entire regression suite. Even when only one small thing changed.

I thought: what if a tool could tell you exactly what to test, based on what actually changed?

So I started building one. And to validate it, I needed real code. Real commits. Real bugs.

That's how I ended up contributing to three major open source repositories.

---

Repo 1 — MoneyPrinterTurbo (25k+ ⭐)

Bug: Groq provider had no default model name

While analyzing a recent commit that added Groq as an LLM provider, I noticed something inconsistent.

Every other provider in llm.py had a default model name configured:

# Other providers — defaults exist
g4f        → "gpt-3.5-turbo-16k-0613"
gemini     → _DEFAULT_GEMINI_MODEL

# Groq — no default ❌
groq_model_name = ""

The WebUI had a default (llama-3.3-70b-versatile), but users running via config.toml only — without the WebUI — would hit a validation error silently.

The fix: Add a service-side default for Groq in llm.py, consistent with other providers.

Harry (the maintainer) reviewed it, agreed, and merged it. ✅

---

Bug 2: CLI validation gaps for --video-source local

A second analysis found two validation gaps in the newly added CLI:

1. --stop-at terms silently returned empty terms when --video-source local was set — no error, no warning, just {"terms": ""}.

2. Missing --video-materials was only caught after expensive LLM + TTS steps completed — failing at Step 5 with a generic error, wasting all that compute.
   

# Fix — fail fast at parse time
if args.video_source == "local" and not args.video_materials:
    parser.error("--video-materials is required when --video-source is local")

Both guards were added. PR merged. ✅

---

Repo 2 — CodeceptJS (10k+ ⭐)

Bug: --shuffle flag silently ignored

This one was subtle. A previous PR (#5438) had added this.testFiles.sort() in run() to fix worker suite distribution — a correct fix for that problem. But it introduced a regression:

// loadTests() — shuffles correctly when --shuffle is set
if (this.opts.shuffle) {
  this.testFiles = shuffle(this.testFiles)  // ✅
}

// run() — always sorts, silently overwriting the shuffle ❌
this.testFiles.sort()

Every time --shuffle was set, the randomized order was immediately overwritten by the unconditional sort. The flag appeared to work — no error, no warning — but tests always ran in the same alphabetical order.

Fix: One guard condition:

if (!this.opts.shuffle) {
  this.testFiles.sort()
}

DavertMik — the creator of CodeceptJS — reviewed and merged it.

"Thank you for catching it!" — his exact words. ✅

---

Repo 3 — Magento / Adobe Commerce (14k+ ⭐)

Bug: Race condition crashes entire bulk price update batch

While reviewing a recent commit (ACP2E-4998) that fixed a NoSuchEntityException in TierPriceValidator, I noticed the fix was incomplete.

The same race condition existed in a sibling class — InvalidSkuProcessor — which is used by all three bulk price APIs (base price, special price, tier price).

The flow:

1. retrieveProductIdsBySkus() builds a list of valid SKUs
2. productRepository->get($sku) is called on each SKU — without a try/catch
3. If a product is deleted between steps 1 and 2 (concurrent catalog modification), NoSuchEntityException propagates uncaught and kills the entire batch — all other valid SKUs are discarded silently

// Before — crashes entire batch if product deleted between lookup and fetch
if ($allowedPriceTypeValue && $type == Type::TYPE_BUNDLE) {
    $product = $this->productRepository->get($sku);  // ⚠️ throws if deleted
    if ($product->getPriceType() != $allowedPriceTypeValue) {
        $valueTypeIsAllowed = true;
    }
}

// After — graceful handling
try {
    $product = $this->productRepository->get($sku);
    if ($product->getPriceType() != $allowedPriceTypeValue) {
        $valueTypeIsAllowed = true;
    }
} catch (NoSuchEntityException $e) {
    $skuDiff[] = $sku;  // treat as invalid SKU and continue
}

The same pattern was already fixed in TierPriceValidator::checkQuantity() — InvalidSkuProcessor was just missed.

PR submitted and all tests passing (Unit, Static, WebAPI). Under review by the Adobe team. 🤞

---

What I Learned

1. Real bugs hide in plain sight

None of these were exotic vulnerabilities. They were logic gaps — a missing guard, a missing default, a flag that silently did nothing. The kind of thing that slips through because the code runs, it just doesn't work correctly.

2. One commit tells a story

Looking at a commit in isolation is powerful. The Groq bug was visible because I was focused on just that commit — what changed, what didn't, what should have changed but wasn't touched.

3. Open source maintainers are generous

Every maintainer responded quickly, reviewed carefully, and gave detailed feedback — even when they disagreed. Harry, DavertMik, the Magento team — all professional and kind.

4. Validation matters

Not every finding was correct. One security analysis I submitted was rejected — the maintainer showed me defense layers I hadn't seen (framework-level sanitization that wasn't visible from the diff alone). That's part of the process. The goal is to be genuinely helpful, not to rack up PRs.

---

What's Next

I'm continuing to analyze more repositories using the same methodology. If you're a maintainer and want a free regression analysis of a recent PR or commit — feel free to reach out.

And if you're a QA engineer wondering whether open source contribution is worth your time — it absolutely is. You learn faster, you build credibility, and you contribute something real.

---

Thanks for reading. If this was useful, I'd love to hear your thoughts in the comments.