Repository: facebook/react
File: packages/react-reconciler/src/ReactFiberWorkLoop.js (JavaScript)

Code before:
  // retries or transitions). It's been like this for a while, though, so fixing
  // it probably isn't that urgent.
  if (remainingLanes === NoLanes) {
    // If there's no remaining work, we can clear the set of already failed
    // error boundaries.
    legacyErrorBoundariesThatAlreadyFailed = null;
  }

  if (__DEV__) {
    if (!rootDidHavePassiveEffects) {
      commitDoubleInvokeEffectsInDEV(root, false);
    }
  }

  const renderPriority = lanesToEventPriority(lanes);
  onCommitRootDevTools(finishedWork.stateNode, renderPriority);

  if (enableUpdaterTracking) {
    if (isDevToolsPresent) {
      root.memoizedUpdaters.clear();
    }
  }

  if (__DEV__) {
    onCommitRootTestSelector();
  }

  if (recoverableErrors !== null) {
    const prevTransition = ReactSharedInternals.T;
    const previousUpdateLanePriority = getCurrentUpdatePriority();
    setCurrentUpdatePriority(DiscreteEventPriority);
    ReactSharedInternals.T = null;
    try {
      // There were errors during this render, but recovered from them without
      // needing to surface it to the UI. We log them here.
      const onRecoverableError = root.onRecoverableError;
      for (let i = 0; i < recoverableErrors.length; i++) {
        const recoverableError = recoverableErrors[i];
        const errorInfo = makeErrorInfo(recoverableError.stack);
        if (__DEV__) {
          runWithFiberInDEV(
            recoverableError.source,
            onRecoverableError,
            recoverableError.value,
            errorInfo,
          );
        } else {
          onRecoverableError(recoverableError.value, errorInfo);
        }
      }
    } finally {

Review comment (suggestion):
This one is a bit strange because the profiler in devtools tracks the priority level that the commit phase is running in rather than what priority was rendered and then committed. I think the idea is that it would be running in the scheduler priority of the render but that's not necessarily the case for the commit.

Code after:
    // schedule a callback until after flushing layout work.
    rootWithPendingPassiveEffects = root;
    pendingPassiveEffectsLanes = lanes;
  } else {
    // There were no passive effects, so we can immediately release the cache
    // pool for this render.
    releaseRootPooledCache(root, root.pendingLanes);
    if (__DEV__) {
      nestedPassiveUpdateCount = 0;
      rootWithPassiveNestedUpdates = null;
    }
  }

  // Read this again, since an effect might have updated it
  let remainingLanes = root.pendingLanes;

  // Check if there's remaining work on this root
  // TODO: This is part of the `componentDidCatch` implementation. Its purpose
  // is to detect whether something might have called setState inside
  // `componentDidCatch`. The mechanism is known to be flawed because `setState`
  // inside `componentDidCatch` is itself flawed — that's why we recommend
  // `getDerivedStateFromError` instead. However, it could be improved by
  // checking if remainingLanes includes Sync work, instead of whether there's
  // any work remaining at all (which would also include stuff like Suspense
  // retries or transitions). It's been like this for a while, though, so fixing
  // it probably isn't that urgent.
  if (remainingLanes === NoLanes) {
    // If there's no remaining work, we can clear the set of already failed
    // error boundaries.
    legacyErrorBoundariesThatAlreadyFailed = null;
  }

  if (__DEV__) {
    if (!rootDidHavePassiveEffects) {
      commitDoubleInvokeEffectsInDEV(root, false);
    }
  }

  const renderPriority = lanesToEventPriority(lanes);
  onCommitRootDevTools(finishedWork.stateNode, renderPriority);

  if (enableUpdaterTracking) {
    if (isDevToolsPresent) {
      root.memoizedUpdaters.clear();
    }
  }

  if (__DEV__) {
    onCommitRootTestSelector();
  }