DEV Community: Tyler Francis

The Regex Bug That Passes Code Review, Passes Tests, and Takes Down Prod

Tyler Francis — Thu, 30 Jul 2026 05:50:18 +0000

Here's a regex. It validates that a string is a list of comma-separated words. Twelve characters. Take a second and decide whether you'd approve it in a PR.

const RE = /^(\w+,?)+$/;

I'd have approved it. It reads correctly, it does what it says, and it passes every test you'd naturally write:

RE.test("alpha")                  // true,  instant
RE.test("alpha,beta,gamma")       // true,  instant
RE.test("alpha,,beta")            // true,  instant
RE.test("")                       // false, instant

Now hand it a string that is 30 characters long and doesn't match:

RE.test("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!")

On my machine that call doesn't return. Not "returns slowly" — the event loop is gone. Node is pinned at 100% of one core doing regex backtracking, and because JavaScript's regex engine has no timeout and no interrupt, nothing you can do from JS will stop it. No AbortController, no Promise.race, no setTimeout. The only exit is killing the process.

If that regex is validating a request body, you have just shipped a single-request denial of service.

Why it explodes

The problem is (\w+,?)+. There's an unbounded quantifier + inside a group that is itself repeated with +. That means there are multiple distinct ways for the engine to divide the same input between iterations.

Given aaa, the group can match:

aaa in one iteration
aa then a
a then aa
a then a then a

Four ways to match three characters. The engine has to try all of them before it can conclude the string doesn't match, because the failing character is at the end. That's 2^(n-1) paths. At n=30 you're around 500 million. At n=40 you're past 500 billion and the heat death of the universe is a more realistic completion estimate than your request timeout.

The technical name is catastrophic backtracking. The security name is ReDoS — Regular Expression Denial of Service, CWE-1333.

The reason it survives review is that every failure mode is invisible from the code and from the happy path. The regex is short. It's readable. It has no obvious "hot spot." And it is instantaneous on every input that matches. You only see it on inputs that nearly match and then fail late — which is exactly the input an attacker sends and almost never the input a test suite contains.

The three shapes to look for

After staring at a lot of these, they mostly reduce to three patterns.

1. Nested unbounded quantifiers. A quantified group whose body can also repeat.

/(a+)+$/
/(\w+\s?)+$/
/^(\d+,)*\d+$/     // this one is fine, actually — see below

The third is safe because \d+, ends in a mandatory literal ,. That comma anchors each iteration, so there's exactly one way to split the input. The presence of nesting isn't sufficient on its own — ambiguity is what matters. Nesting is just the most common way to get it.

2. Ambiguous alternation inside a repeat. Branches that can match the same text.

/^(\w|\d)+$/

\d is a subset of \w. Every digit can be matched by either branch, so an n-digit string has 2^n paths through the group. This one hides better than nested quantifiers because there's no visible nesting at all.

3. Overlapping adjacent quantifiers.

/^\s*\s*$/
/^.*.*=.*$/

Two adjacent quantifiers over intersecting character classes. Any character matched by the first could equally have been matched by the second.

The advice you'll find online is wrong for JavaScript

Search for how to fix catastrophic backtracking and the top answer is almost always: wrap the inner group in an atomic group, (?>...), or use a possessive quantifier, a++. Atomic groups tell the engine "once you've matched this, never give the characters back," which kills the backtracking outright.

This is correct advice. It is also not available in JavaScript. JS regex has no atomic groups and no possessive quantifiers. /(?>a+)/ is a syntax error. /a++/ is a syntax error — + is not a valid quantifier target.

I found this out the annoying way: an early version of a rewrite suggester I wrote emitted a++ as its fix. It looked right, it matched the advice everyone gives, and it was unrunnable JavaScript. The corrected version has to separate the base atom from its own quantifier before recombining, because \w+ and \w are different things and you can't blindly append to the end of an arbitrary token.

The closest JS gets is an atomic-group emulation using a lookahead plus a backreference:

// atomic (?>\w+) emulated
/(?=(\w+))\1/

That works, but it is unreadable, and in most real cases you don't need it. The two fixes that actually apply:

Make the ambiguity impossible. Rewrite so there's exactly one way to split the input.

// before: /^(\w+,?)+$/
// after:
/^\w+(?:,\w+)*,?$/

Each iteration now starts with a mandatory ,. No ambiguity, linear time, same accepted language.

Or stop using a regex. For the comma-separated-words case:

const ok = s.length > 0 && s.split(",").every(p => /^\w*$/.test(p));

Uglier. Also unconditionally linear, and obviously correct to the next person who reads it. A lot of ReDoS bugs exist because a regex was reached for on reflex where a split would have done.

And regardless: bound your inputs. if (input.length > 256) return false; before the test caps the worst case no matter what the pattern does. It is not a fix — the exponent is still there, you've just chosen an exponent you can survive. Do it anyway. It's one line and it turns a total outage into a slow request.

Testing for this is trickier than it looks

The obvious approach is to run the regex against a generated attack string and time it. Don't do that in the process you care about — that's the same single-request DoS, self-inflicted. If you're going to time it, do it in a worker thread or a child process you can kill:

// crude but honest
const { Worker } = require("node:worker_threads");
const w = new Worker(`
  const { workerData, parentPort } = require("node:worker_threads");
  const t = Date.now();
  new RegExp(workerData.src).test(workerData.input);
  parentPort.postMessage(Date.now() - t);
`, { eval: true, workerData: { src: "^(\\\\w+,?)+$", input: "a".repeat(30) + "!" } });

const timer = setTimeout(() => { w.terminate(); console.log("VULNERABLE: timed out"); }, 2000);
w.on("message", ms => { clearTimeout(timer); console.log("ok:", ms, "ms"); });

Better still is to not execute the pattern at all. You can determine ambiguity by parsing the regex into an AST and checking the structural properties — whether a quantified node's body is nullable or self-overlapping, whether alternation branches have intersecting first-character sets, whether adjacent quantifiers overlap. That's static analysis, it terminates, and it never runs untrusted input through an engine with no timeout.

That's the approach I ended up taking. I wrote a small MCP server that does exactly this, because I wanted my own agent to be able to check a regex before writing it into a codebase rather than after: regex-safety-audit-mcp. It parses the pattern into a real hand-written AST — not string heuristics — flags nested unbounded quantifiers, ambiguous alternation inside repeated groups, and backreferences, and generates an attack string for you to test in your own sandboxed process. It never executes the pattern itself. A regex-safety tool that runs untrusted regexes to see if they're slow would be a fairly funny way to get owned.

Three tools: analyze_redos_risk, generate_attack_string, suggest_safe_rewrite. Free tier if you just want to throw a few patterns at it.

The part worth remembering

Grep your codebase for )+, )*, ){2,} — quantifiers applied to groups. Most of them are fine. The ones where the group's body ends in another unbounded quantifier are worth thirty seconds each.

And check the regexes you didn't write. Copy-pasted email validators are a famously rich source; the "RFC 5322 compliant" one that circulates on Stack Overflow has bitten multiple production systems. So has the default URL-matching regex in more than one popular library. The bug doesn't care that you got the pattern from a trustworthy-looking place.

If you've hit one of these in production, I'd genuinely like to hear which pattern did it — the catalog of real-world offenders is more useful than any general rule.

Modeling Prop Firm Trailing Drawdown in Pine Script (So Your Backtest Stops Lying)

Tyler Francis — Fri, 12 Jun 2026 20:03:47 +0000

If you write TradingView strategies for futures prop firm accounts (Apex, Topstep, MyFundedFutures), there's a structural problem with your backtest: Pine Script's strategy() framework evaluates terminal equity, but prop firms evaluate a path-dependent constraint called trailing drawdown. A strategy can be profitable in the Strategy Tester and still fail evals consistently. Here's how to model the constraint correctly.

What trailing drawdown actually does

On most futures firms, your drawdown floor ratchets up with your account's high-water mark — and on many firms, that high-water mark includes unrealized profit. If you're up $600 open on a trade and it stops out at breakeven, your closed P&L is unchanged but your drawdown floor moved up $600 permanently. The backtest sees a scratch. The eval sees lost cushion.

Step 1: Track the unrealized high-water mark

//@version=6
strategy("Eval-Aware Backtest", overlay=true,
     initial_capital=50000, commission_type=strategy.commission.cash_per_contract,
     commission_value=0.67, slippage=1)

float liveEquity = strategy.equity

var float hwm = strategy.initial_capital
hwm := math.max(hwm, liveEquity)

strategy.equity in Pine already includes open profit, which is what we want for the high-water mark approximation. Run this on 1-minute bars for the closest approximation to tick-level ratcheting.

Step 2: Compute the trailing floor and breach condition

float trailDD = 2500.0  // 50k account, typical
float floorLevel = hwm - trailDD

float floorCapped = math.min(floorLevel, strategy.initial_capital + 100)

bool breached = liveEquity <= floorCapped
var bool evalFailed = false
if breached
    evalFailed := true
    strategy.close_all(comment="DD BREACH")

Step 3: Gate entries on eval state

bool profitTargetHit = strategy.equity >= strategy.initial_capital + 3000
bool canTrade = not evalFailed and not profitTargetHit

if canTrade and longSignal
    strategy.entry("L", strategy.long)

Once evalFailed flips, the account is dead — letting the backtest keep trading after a breach is the single most common way Pine backtests overstate eval performance.

Step 4: Report what matters

var table t = table.new(position.top_right, 1, 3)
if barstate.islast
    table.cell(t, 0, 0, evalFailed ? "EVAL FAILED" : profitTargetHit ? "EVAL PASSED" : "IN PROGRESS")
    table.cell(t, 0, 1, "Floor: " + str.tostring(floorCapped, "#.00"))
    table.cell(t, 0, 2, "Cushion: " + str.tostring(liveEquity - floorCapped, "#.00"))

Net profit is now a secondary metric. The number you optimize is whether the path ever touched the floor.

What changes when you do this

When I retrofitted this onto a library of strategies that all looked fine in the standard tester, about two-thirds failed simulated evals. The failures clustered: strategies with high MAE relative to target, and strategies with win rates under 40%.

The survivors — low MAE, 40-60% win rate, hard daily-loss gating — are a genuinely different population than "most profitable backtest." That's the core insight: the eval is a different objective function, and you have to encode it.

Run your own strategies through this harness before paying for another evaluation. If you'd rather start from strategies already built and validated against these exact constraints — with full source code so you can verify everything — that's what I sell at propfirmpinescripts.com, alongside free tools (drawdown calculator, eval simulator) that run this math in the browser.

I Built a Side Project Selling Pine Script Strategies for Prop Traders

Tyler Francis — Fri, 29 May 2026 21:23:33 +0000

Started propfirmpinescripts.com a while back selling pine script strategies for futures prop firm traders. Figured I would share some of what worked and what has not.

The problem I was solving

I was actually trading on Apex myself and kept running into the same thing. Every pine script strategy I found online was not built for prop firm rules. Daily loss limits not enforced in code. No end of day flatten. Blew an evaluation partly because of it.

Figured other traders had the same problem. Coded the rules myself, then decided to sell the scripts.

What I built

Pre-built pine scripts for 4 instruments: GC (gold futures), MES (micro S&P), MNQ (micro Nasdaq), CL (crude oil). Each one has daily loss lock, EOD flatten, win lock coded in. You can configure the limits for different firms without touching the core logic.

Priced at $50 for a single script or $150 for all 4.

What actually moved conversions

Adding real payout screenshots. Like actual Apex payout certificates from traders who passed using the strategies. Before I did that — traffic but weak conversions. After — noticeably better.

Prop firm traders do not trust backtest results at all anymore. Too many people have gamed them. A real funded account payout is the only thing that actually means something to them.

Where things are at

Still early. Revenue is real but small. Building more SEO content, getting into prop firm communities, and eventually a subscription tier for updates when firms change their rules.

If you are a dev with trading knowledge this space is underbuilt.

Apex Trader Funding vs Topstep: Best Prop Firm for Algo Traders in 2025

Tyler Francis — Fri, 29 May 2026 21:23:31 +0000

I have tried a few prop firms at this point and the rules are genuinely different in ways that matter if you are running automated strategies. Here is my take after actually trading through evaluations on each.

The thing that changes everything: consistency rules

Apex Trader Funding has no consistency rule. I cannot overstate how much better this is for algo trading. Your system can have a huge trending day and it does not hurt you at all.

Topstep has a 30% rule. Your single best day cannot be more than 30% of your total evaluation profit. So if your algo catches a 200 tick CL move that represents 35% of your week profit, you are potentially failing even though you were profitable. This is not theoretical — it happened to me.

MyFundedFutures has no consistency rule, trailing drawdown of $2,200 on $50k. Good option.

FTMO has no consistency rule, 5% daily loss limit, good for automated strategies.

The instrument selection matters too

Apex has GC, CL, MES, MNQ, ES, NQ, M2K, ZB, ZN and more. Topstep is more limited — mainly the equity index micros. If you are running a gold or crude oil strategy you basically have to go with Apex or FTMO.

My recommendation

Apex if you are automating. Better rules, way more instruments, and the trailing drawdown model actually makes sense from a risk management perspective.

I sell pre-built scripts specifically for Apex at propfirmpinescripts.com — 4 strategies across GC, MES, MNQ, and CL with all the rules coded in. Tested on actual evaluations.

How to Build a Pine Script Strategy That Passes Prop Firm Evaluation

Tyler Francis — Fri, 29 May 2026 21:23:28 +0000

So I spent a while getting burned on prop firm evaluations before I figured this out. The issue was that my Pine Script was not built with prop firm rules in mind. Most scripts you find online are not. Here is what actually needs to be in your code.

Daily Loss Lock

This is the big one. Your script has to stop trading automatically if you hit the firm daily drawdown. Do not rely on yourself to close manually — you will miss it eventually.

On Apex that is $2,500 on a $50k account. Topstep is only $1,000. Code it in:

var float dayStart = na
if dayofweek != dayofweek[1] or na(dayStart)
    dayStart := strategy.equity
float dailyPnL = strategy.equity - dayStart
if dailyPnL <= -2500
    strategy.close_all("daily loss limit hit")

End of Day Flatten

Every prop firm requires you to be flat before session close. 3:55pm CT for CME futures.

if hour == 15 and minute >= 55 and strategy.position_size != 0
    strategy.close_all("EOD flatten")

Apex vs Topstep for algos

Apex has no consistency rule at all. Topstep caps your best single day at 30% of your total eval profit. If your algo has a great trending day it can actually hurt you on Topstep. I break this down at propfirmpinescripts.com.

Pre-built compliant scripts

If you want scripts that already have all this coded in, they are at propfirmpinescripts.com. The bundle includes 4 strategies for GC, MES, MNQ, and CL — all with EOD flatten, daily loss locks, and win locks built in.