devtools: inferred action name is corrupted when caller's source path contains spaces

[happyTaher]

Summary

When setState is called without an explicit action name, the devtools middleware infers the action name from the call stack. The regex used to parse a V8 stack frame is:

const v8StackLineRe = /.+ (.+) .+/

This captures the token between two spaces. If the caller frame's source path contains a space, the greedy match lands inside the path and the wrong text is used as the action name in Redux DevTools.

Affected cases

Common real-world paths with spaces:

• webpack namespaces, e.g. at Object.increment (webpack://my app/./src/store.js:10:5) → action name becomes "(webpack://my"
• Windows paths, e.g. at increment (C:\Program Files\app\store.js:10:5) → action name becomes "(C:\Program"

Expected action name in both cases: increment (or Object.increment).

Reproduction (regex in isolation)

const re = /.+ (.+) .+/
re.exec('at Object.increment (webpack://my app/./src/store.js:10:5)')[1]
// => "(webpack://my"   (expected: "Object.increment")

Impact

Cosmetic — devtools-only. Actions still dispatch correctly; only the displayed action label is wrong. Paths without spaces and anonymous frames are unaffected.

Fix

Anchor the match to at and stop at the first (: /^at (.+?) \(/. This is equivalent on all space-free paths (and on the cases covered by the existing tests) and fixes the spaced-path cases. PR incoming with a deterministic test.

[dai-shi]

Thanks for reporting.

[dai-shi]

Please check #3531

[MILLERMARRU]

The diagnosis and the direction of the fix are both right, worth flagging one thing before the PR lands though: the proposed regex changes the output for a couple of frame shapes that aren't in the bug report but are common in real stacks.

Testing both regexes against a broader set of realistic V8 frames:

at Object.increment (webpack://my app/./src/store.js:10:5)   old: "(webpack://my"    new /^at (.+?) \(/: "Object.increment"
at increment (C:\Program Files\app\store.js:10:5)            old: "(C:\Program"      new: "increment"
at async Object.increment (file.js:10:5)                     old: "Object.increment" new: "async Object.increment"
at new Foo (file.js:10:5)                                    old: "Foo"              new: "new Foo"

The two reported cases (spaced webpack path, Windows path) come out right either way, but async functions and constructor calls pick up an "async "/"new " prefix they didn't have before, since the old regex's leading .+ greedily ate through those keywords along with everything else up to the last space.

Anchoring past an optional async/new keyword keeps parity with the current output for those cases while still fixing the spaced-path bug:

const v8StackLineRe = /^at (?:new |async )?(.+?) \(/

Re-running the same set of frames through that version gives Object.increment, increment, Object.increment (async stripped, matching old behavior), and Foo (new stripped, matching old behavior), alongside the two originally reported cases. Might be worth folding into the incoming PR's test cases alongside the space-in-path ones.

[dai-shi]

Updated #3531.