Developing with a framework like React can add a level of complexity to debugging. Hooks like useEffect can often be a culprit, because it can be configured to only run during certain renders. If you rely on a hook running and it doesn’t, this can cause issues. Here’s a real world example of debugging a useEffect bug in Replay DevTools.
The bug
We received reports that sometimes the tooltip that displays the line hit count would be stuck in a loading state forever. This was an intermittent bug, making it harder to pin down because it couldn’t always be reproduced. Fortunately with replay, once we were able to record the bug, we had a debuggable reproduction to work with.
With a bug like this, there could be a lot of things going on. It could be a backend error, network request related, or the result of something going wrong in the front end. Replay engineer Josh Morrow describes his debugging process below.
The debugging process
Create a reproducible example
This replay captures the bug behavior.
In the replay, we can see the tooltip working properly initially, with line hit counts displayed when hovering over the line of code.
There is a click on a comment, which opens a new source in the replay. In Replay, comments can be linked to a specific line of code, so clicking the comment automatically opens the editor and focuses on the line of code.
After this, the tooltip always shows Loading...
on hover.
Understand expected behavior
Replay will fetch the number of times a line of code has executed and display that number in a tool tip when you hover on the line. There is a LineNumberToolTip
component that handles this functionality on the front end.
We can see in the replay that the updateBreakpointHitCounts
function executes early in the replay, and we can see the tooltip updating with the line hit count as expected. The two hits of this function line up with the application working properly in the UI.
Once we understand how the application is supposed to act, we can investigate the point where it doesn’t behave in this same way.
Isolate the issue
The updateBreakpointHitCounts
does not execute after the new source is opened. This clues us in that whatever triggers that function is not working properly.
We can see that setBreakpointHitCounts
within the setHoveredLineNumber
function does execute at the proper locations, so we can narrow in to functionality between this function and updateBreakpointHitCounts
, which doesn’t execute as expected.
Logging the parameters of setBreakpointHitCounts
shows that the line number changes, but the source id is the same for the entire replay. This means that even though a different file is open in the editor, the LineNumberTooltip
component thinks we are still in the same file as before.
In this video below, Josh outlines how he isolated the issue to the sourceId
value.
Tracing the root cause
Now that we have isolated the issue to the source id not updating, we can dig in and investigate why.
Within the LineNumberToolTip
component on line 89
, we are getting the source from useSelector
. By logging the source.id
on the next line, we can see that it does update correctly. (Read more about why we log the value on the next line in our documentation here).
However, this updated value is not being passed into setBreakpointHitCounts
, because when that function executes, it always uses the stale sourceId
.
So what’s going on here? The function setBreakpointHitCounts
is being called inside a defined function, setHoveredLineNumber
. When you define a function in JavaScript, you create what’s called a closure. This means that the value of sourceId
when the function is defined, is what the value will always be inside that particular function definition. (You can read more about closures here). When you have a bug where a particular value is not updating as expected or evaluating as a stale value, one of the first questions to consider if whether you’re dealing with the effect of a closure.
The setHoveredLineNumber
function is being called inside a useEffect
hook in the LineNumberTooltip
component on line 142
. This hook calls the setHoveredLineNumber
function whenever we hover over a line, but because of the closure created by useEffect
, the original sourceId
is still being used.
The fix
Here is the pull request with the fix.
To dig into what’s happening here — the setHoveredLineNumber
function declaration is re-executed every time the component renders. However, the function is being assigned to the editor.codemirror.on
hook on line 142
inside the useEffect
hook. This creates another closure around the assignment of setHoveredLineNumber
with the original sourceId
value.
The useEffect
hook is configurable, so it may or may not run on every render. In this case, by passing an empty array as the second parameter, we are telling useEffect
to only run once when the component is mounted. This means that even if the updated sourceId
is passed to the setHoveredLineNumber
function in a new declaration, the original assignment with the original value is still being used.
In the fix, we pass source
as a value to the array in the second parameter. This means that the useEffect
hook will run again whenever the value of source
is updated. This way, we always use the correct sourceId
when assigning setHoveredLineNumber
.
In the video below, Josh digs into the root cause and how it was ultimately resolved.
Learn more
Replay has React DevTools built in so you can debug issues related to components, props, and state. Check out our documentation here for more examples.
Top comments (0)