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.