-
Notifications
You must be signed in to change notification settings - Fork 46.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: "Should have a queue. This is likely a bug in React" #30038
Comments
This occurs ONLY on the first instance of taking the "problematic action" that causes the bug, and only if take on the the first mount of the problem component. Identical actions after this crash has occurred and the component is re-mounted via the This extremely strange circumstance is making debugging unrelated issues quite difficult. |
This is really plaguing us. I hope this can be resolved. |
Friendly bump. I know this seems like impatience but an unmitigatable bug in React is a big problem for us. |
Calling hooks conditionally usually leads to these kind of bugs. If you want help fixing this issue, we need a minimal reproduction. |
Thanks for your reply @eps1lon. We're 100% not calling hooks conditionally. I manually reviewed the code three times, asked ChatGPT, and ESLint also agrees. Unfortunately I have no idea what code is really causing the problem because commenting out the "problem hook" is what leads to this error. How can I glean any clue about the underlying cause? I can't share our private code and the error message provides not a single avenue to pursue. It would be a different thing if I knew commenting out some code resolved an issue - but in this case it causes the issue. |
I'd start by removing surrounding code until it no longer reproduces. It might also be a sibling or parent component that calls hooks conditionally. |
Thanks for the advice @eps1lon! I'll see if I can uncover anything. |
Results in error: export const useEditExploreCapabilities = ({
noEdits,
isHashtag,
}) => {
const [canEdit, setCanEdit] = useState(!noEdits && !isHashtag);
const [canExplore, setCanExplore] = useState(canEdit);
useEffect(() => {
setCanEdit(noEdits && !isHashtag);
}, [noEdits, isHashtag]);
useEffect(() => {
setCanExplore(canEdit || (isHashtag));
}, [isHashtag, canEdit]);
return [canEdit, canExplore];
}; Works fine: export const useEditExploreCapabilities = ({
noEdits,
isHashtag
}) => {
const [canEdit, setCanEdit] = useState(!noEdits && !isHashtag);
const [canExplore, setCanExplore] = useState(canEdit);
useEffect(() => {
setCanEdit(!noEdits && !isHashtag);
setCanExplore(canEdit || (isHashtag));
}, [noEdits, isHashtag, canEdit]);
return [canEdit, canExplore];
}; Is this expected? As far as I'm aware my original code didn't break any rules of hooks and seems, on the surface, more correct to me. |
I can't repro this in isolation: https://codesandbox.io/p/sandbox/cranky-currying-gn777q-gn777q Maybe another component in your tree is violating Rule of React? For minimal reproductions, try to remove as much as possible from the whole component tree. |
I am quite certain no rules of React (most especially rules of hooks) are being broken. ESLint agrees. I'm the only developer. Since I have found a workaround I won't have time to work on this, but despite the inability to reproduce it in isolation, I feel confident this is a bug in React. The fact it was masked under other React errors further bolsters my belief. |
For what it's worth, this is inside |
React version: 18.2.0
(18.2.0 is required by Expo, but theoretically equivalent to 18.3.1 for this purpose)
Steps To Reproduce
Code example:
I don't know how to reproduce this. Originally I faced #22049, supposedly caused by our "problem hook":
and removing the hook causes this instead:
Error: Should have a queue. This is likely a bug in React. Please file an issue.
The current behavior
Using our simple hook causes #22049 - and removing our hook causes this issue instead
The expected behavior
Using React as specified in the docs causes no errors
The text was updated successfully, but these errors were encountered: