Fix form status reset when component state is updated

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!

[eps1lon]

Alternate to #33351 without the regression highlighted in #33351 (comment)

Host context is now updated in pushHostContext (similar to normal React Context) in addition to during updateHostComponent.

Closes#30368
Closes#33351

[react-sizebot]

Comparing: eb89912...aa288b5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.05%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	608.26 kB	608.36 kB	+0.01%	107.67 kB	107.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	=	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	667.37 kB	667.47 kB	+0.01%	117.55 kB	117.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	693.56 kB	693.67 kB	+0.01%	122.05 kB	122.06 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.99 kB	684.10 kB	+0.01%	120.43 kB	120.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against aa288b5

[eps1lon]

I'm not sure I fully understand this comment. If something suspends we pop back up. And the Component we're rendering (here: TransitionAwareHostComponent) should not be able to read the current Context just yet which is what pushing the context before the render would do, right? We can't nest Host Context anyway though. So this seems safe to move the push after the render.

[sebmarkbage]

A common issue is that CompleteWork and UnwindWork unconditionally calls popHostContext. That's called even when something in the component suspends because it doesn't know if we suspended before or after the push. There's no state to indicate that.

That's why we always pushHostContext and other push things immediately when we enter the update before anything could error or suspend.

Since renderTransitionAwareHostComponentWithHooks might suspend, I don't think it's safe to move the pushHostContext after it. In fact I'm surprised we don't have a test that fails for that case. Maybe we're lacking coverage or there's some other thing that covers it but it shouldn't be safe in general.

[eps1lon]

Makes sense. Moved the pushContext back to its original place. When the state changes, we update the context value which works because only a single transition provider is allowed.

Basically, we set the value on pushHostContext and when we update state.

[acdlite]

Can you revert this comment back to the original now too please?

[syedarman7867867860-bit]

Sorry 😟

[redbmk]

Would love to see this merged in soon. We're blocked from upgrading to Next 15 and React 19 until this issue is fixed - will also have to wait for Next to pull in a new canary release after this is merged.

@sebmarkbage any chance you could review the most recent changes?

[devongovett]

Is there a release planned that might include this fix? This is still an issue in the latest stable version.

[redbmk]

@devongovett it looks like it's fixed in 19.2

Screen.Recording.2026-04-17.at.5.39.21.PM.mov

Compare that with the behavior here: #31363 (comment)

how are you recreating it?

[RomkeSandwave]

I'm still noticing this issue on 19.2.5:

typeButtonProps=DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>,HTMLButtonElement>functionSubmitButton(props: PropsWithChildren<ButtonProps>): React.JSX.Element{const{pending}=useFormStatus()const[debouncedPending,setDebouncedPending]=useState(false)useEffect(()=>{if(pending){consthandler=setTimeout(()=>{setDebouncedPending(true)},400)return()=>{clearTimeout(handler)setDebouncedPending(false)}}else{setDebouncedPending(false)}},[pending])console.log({pending, debouncedPending});return<Button{...props}type="submit">{props.children}{pending&&debouncedPending&&<Spinner/>}</Button>}

Without the effect the pending stays true until the form action completes. With the effect pending immediately resets back to false.

[redbmk]

it looks like it's fixed in 19.2

OK I was wrong... the react.dev site SAYS 19.2, but the site itself is actually using a canary build of 19.3.

The problem is React rarely pushes new stable builds and when they do it's usually for major security bugs. 19.2.0 was published back in October and there have only been 13 commits between then and 19.2.5 which was just released a couple weeks ago. Meanwhile, there have been 492 commits between 19.2.0 and the latest commit in main, including this PR.

React seems to want you to use frameworks like nextjs that depend on canary builds rather than using stable versions. Compare these stackblitz's for example:

• using 19.2.5
• using 19.3.0-canary-142cfde8-20260422

Screen.Recording.2026-04-23.at.9.24.47.AM.mov

So, it is fixed, but it won't be release until 19.3.0 comes out, which could be... who knows when. If you're OK with rolling a canary version you could use the latest. If you're not using NextJS you could at least use the version their latest version is pinned to in hopes that they've done enough vetting to say that version is stable enough for them.

[RomkeSandwave]

Thanks for finding out for us!