Forem: Replay

Debugging a React useEffect bug

Cecelia Martinez — Tue, 19 Apr 2022 14:11:23 +0000

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.

Debugging TypeScript using Replay

Cecelia Martinez — Fri, 18 Mar 2022 20:34:16 +0000

Recently, I sat down with Mateusz Burzyński, aka AndaristRake, to talk about how he debugged an issue in TypeScript using Replay for Node. With the replay-node-cli, you can record a Node runtime for debugging after the fact — no browser required.

The bug

The bug, described in the GitHub issue here, happens when using a newer feature in TypeScript that supports control flow analysis on dependent parameters contextually typed from a discriminated union type. 😅 There’s a lot to unpack there!

Take a look at the example below, and we’ll break it down.

interface Foo {
  method(...args: ['a', number] | ['b', string]): void
};

const methodSyntax: Foo = {
  method(kind, payload) {
    if (kind === 'a') {
      payload.toFixed(); // error, Property 'toFixed' does not exist on type 'string | number'
    }
    if (kind === 'b') {
      payload.toUpperCase(); // error, Property 'toUpperCase' does not exist on type 'string | number'
    }
  }
}

Here we have a union type, which just means a combination of multiple types. The argument for our function can be number | string. A discriminated union means that there is a parameter that helps you distinguish (or discriminate) which type in the union applies (There’s a great blog post here on discriminated unions from CSS-Tricks).

In this case, we should be able to check kind and if it’s a, the type should be narrowed to number. Same goes for b, it should be narrowed to string. This is what is meant by “control flow analysis” — we can use an if statement or other logical check to narrow the type.

However, that’s not working in our example. Instead, the type is still number | string for each parameter.

The debugging process

Mateusz walked us through how he investigated and ultimately identified the root cause of the bug using Replay. These steps can be used for any issue, and are a great example of how a developer debugs in the real world.

Generate a reproducible example

This step was easy thanks to Replay. To get started debugging this issue, Mateusz recorded a small test of the following code. Using replay-node-cli he recorded the run to create a debuggable replay of the bug.

 type Foo = {
  method(...args:
    [type: "str", cb: (e: string) => void] |
    [type: "num", cb: (e: number) => void]
  ): void;
}

// this fails for some reason, as a method
let fooBad: Foo = {
  method(type, cb) {
    if (type == 'num') {
      cb(123) // error!
    } else {
      cb("abc") // error!
    }
  }
};

Identify expected behavior

The next step in debugging is understanding what is supposed to happen when the application works as expected.

The original GitHub issue has a playground reproduction that shows this feature works when using function declaration syntax and manual destructuring, but fails when using the method syntax.

Because the bug only occurs when using the method syntax, we can make an example of what should happen when this works properly. Mateusz also recorded a replay here of the working behavior when using an arrow function syntax.

type Foo = {
  method(...args:
    [type: "str", cb: (e: string) => void] |
    [type: "num", cb: (e: number) => void]
  ): void;
}
// suddenly works for arrow function
let fooOkay1: Foo = {
  method: (type, cb) => {
    if (type == 'num') {
      cb(123)
    } else {
      cb("abc")
    }
  }
};

Understanding what working code looks like is critical to debugging, because it allows you to identify what is different between the working and non-working code.

It also gives you a goalpost for debugging. Before you define your problem, you need to know what the application is expected to do in a given situation.

Define the problem

We are now able to define the problem very specifically. Using a framework of “expected behavior” and “actual behavior” is a clear way to define the bug.

✅ Expected behavior: TypeScript should narrow the type of a discriminated union when using control flow analysis in a declared method.

🚫 Actual behavior: TypeScript does not narrow the type in declared method only.

Now that we know the problem, we can start investigating why it occurs.

Isolate the issue

Next was understanding where in the code the error was actually happening. To do this, it’s important to understand what code executed at the time the error occurred.

Replay helps with this by showing how many times a given line of code was hit during the recording. You can also lock in to a specific instance of that code’s execution to inspect your application values at that time.

Mateusz started with the getDiscriminantPropertyAccess function, which takes in computedType and expr parameters. From reviewing the code when this feature was added to TypeScript, he identified this function as related to the narrowing process.

With the Replay console, you can view the value of properties at a given time during the code execution. Once the functions related to the bug have been isolated, the values of these parameters can be evaluated. This can be done with print statements or using the console.

Mateusz output computedType with the helper function .__debugTypeToString() to further evaluate.

The issue here is that the type should come back as either string or number depending on the variable, but instead both are showing a type of string | number which is causing the failure because of a type mismatch.

In the working example, however, the type evaluated correctly as number.

Tracing the root cause

Mateusz then used Replay’s stepping functionality to trace the execution of the code. By comparing the working example with the non-working example, he was able to identify lines that only executed in the working example. The lines after the declaration of access aren’t executed when the bug occurs. We can see in the replay that these lines show 0 hits on hover.

Because access is being evaluated on line 79105 and failing the check, the next step is looking at getCandidateDiscriminantPropertyAccess() to see the return value.

We can see on line 79060 inside this function that reference is being evaluated to see if ts.isBindingPattern() or ts.isFunctionExpressionOrArrowFunction() is true. Because our syntax is method syntax and not a function expression or arrow function, the reference fails the check and the function does not continue.

We can see this by printing the function to the console to see the return value.

Broken version returns false, type is not narrowed

Working version returns true, type is narrowed

The fix

We need to ensure that a function declared with the method syntax also evaluates true within the getCandidateDiscriminantPropertyAccess() function so it is narrowed appropriately.

Here is the pull request with the suggested resolution by Mateusz, which adds an option for isObjectLiteralMethod() to the check to ensure that method syntax will also trigger the destructuring of the discriminant union. The fix was merged and this bug has officially been resolved! 🥳

👉 Want to record your own Node applications? Check out the Replay Node guide here and let us know at replay.io/discord if you have any questions!