diff --git a/packages/core/src/render3/instructions/change_detection.ts b/packages/core/src/render3/instructions/change_detection.ts
index d2569b4fd5d988..20bc18c01f4f1c 100644
--- a/packages/core/src/render3/instructions/change_detection.ts
+++ b/packages/core/src/render3/instructions/change_detection.ts
@@ -233,24 +233,23 @@ export function refreshView<T>(
         }
         incrementInitPhaseFlags(lView, InitPhaseState.AfterViewInitHooksToBeRun);
       }
-    }
-    if (tView.firstUpdatePass === true) {
-      // We need to make sure that we only flip the flag on successful `refreshView` only
-      // Don't do this in `finally` block.
-      // If we did this in `finally` block then an exception could block the execution of styling
-      // instructions which in turn would be unable to insert themselves into the styling linked
-      // list. The result of this would be that if the exception would not be throw on subsequent CD
-      // the styling would be unable to process it data and reflect to the DOM.
-      tView.firstUpdatePass = false;
-    }
 
-    // Do not reset the dirty state when running in check no changes mode. We don't want components
-    // to behave differently depending on whether check no changes is enabled or not. For example:
-    // Marking an OnPush component as dirty from within the `ngAfterViewInit` hook in order to
-    // refresh a `NgClass` binding should work. If we would reset the dirty state in the check
-    // no changes cycle, the component would be not be dirty for the next update pass. This would
-    // be different in production mode where the component dirty state is not reset.
-    if (!isInCheckNoChangesPass) {
+      if (tView.firstUpdatePass === true) {
+        // We need to make sure that we only flip the flag on successful `refreshView` only
+        // Don't do this in `finally` block.
+        // If we did this in `finally` block then an exception could block the execution of styling
+        // instructions which in turn would be unable to insert themselves into the styling linked
+        // list. The result of this would be that if the exception would not be throw on subsequent
+        // CD the styling would be unable to process it data and reflect to the DOM.
+        tView.firstUpdatePass = false;
+      }
+
+      // Do not reset the dirty state when running in check no changes mode. We don't want
+      // components to behave differently depending on whether check no changes is enabled or not.
+      // For example: Marking an OnPush component as dirty from within the `ngAfterViewInit` hook in
+      // order to refresh a `NgClass` binding should work. If we would reset the dirty state in the
+      // check no changes cycle, the component would be not be dirty for the next update pass. This
+      // would be different in production mode where the component dirty state is not reset.
       lView[FLAGS] &= ~(LViewFlags.Dirty | LViewFlags.FirstLViewPass);
     }
   } catch (e) {
diff --git a/packages/core/test/linker/query_integration_spec.ts b/packages/core/test/linker/query_integration_spec.ts
index fc5e0ce9c057e1..c09d3f61ca3b9c 100644
--- a/packages/core/test/linker/query_integration_spec.ts
+++ b/packages/core/test/linker/query_integration_spec.ts
@@ -685,6 +685,7 @@ describe('Query API', () => {
          const template =
              '<auto-projecting #q><ng-template><div text="1"></div></ng-template></auto-projecting>';
          const view = createTestCmpAndDetectChanges(MyComp0, template);
+         view.detectChanges();
 
          const q = view.debugElement.children[0].references!['q'];
          expect(q.query.length).toBe(1);