jiebi/CodeConvo huggingface dataset:
It looks like this: It happened two times on random commits, and I don't see a pattern. Probably caused by me changing how tasks are distributed between parallel nodes in I don't understand why would try to run before a build exists though (if that's what's happening?)
I think this one would require some experience with CircleCI. I don't have any pointers as to where to start: I don't understand why it's failing myself. So it's not a very beginner-friendly issue (I marked the difficulty as medium for that reason).
Another example:
I want to work on this. After doing some research on circleci document, I didn't find the document said about parallel test and deployment sequence. I'm curious about how circleci deal with parallel test and deployment sequence. I think there are two situations: all parallel test finishes, run deployment sequence. If this is true, I think it won't cause current test error. container runs deployment after the container's test finished. I guess it is more likely in this case. Sometimes it passed, it's because node 2 already built file. Sometimes it failed because node 2 didn't build file yet. So I think maybe that's because each container will run deployment after that node test finished. If the situation is as above, I come up with two solutions. we want to keep current test flow, we can try to keep each node builds time balance. this test at first, then run other test parallel. reference link:
Only node 2 does a full build. So I don't understand how deployment on other nodes could work at all.
Or do nodes share the file system?
I think nodes share the file system. Otherwise, it should fail every time. It will be easier to debug if we can add more log, like current build time and .
Would it make sense to change the upload script to only run on the second node?
Yep, I think so, because in the document I can't ensure whether deployment stage is triggered after all parallel test finished.
Can we just put the deployment command right into the test command? Is there any benefit to separating them?
I think it's also workable, but may lead misunderstanding. Cause we put build process to test stage. Or we can try to use stage. Run at compile stage, so we can promise and stages have needed file.
I've noticed a strange bug with the react redux opt-in. If i use it with a connected class component, everything is ok: If i use it with a connected functional component that use with , i obtain a strange error: in method. I create a codepen to reproduce the issue: PS: Sorry for the cors error, but i don't find the way to add as cdn
I believe the issue here is that expects the second argument to be a function that returns the reference: See: for more information about the API of the hook. Maybe the error thrown could be more clear?
You're right, accept a function as second argument. A warning on wrong argument type could be a good idea.
Ill take this issue on
Sure
i get TypeError: React.useImperativeMethods is not a function in 16.8.0-alpha.1 but when back to 16.7.0-alpha.2 not get this error
The hook was renamed in this PR: Most likely between the 16.7 alpha and 16.8 alpha
Yeah, it was renamed.
yes it work good after rename it where i can get changes between alpha version ?
Commit log. We don't write changelogs for alphas.
I'm taking this in since we want to get Hooks out sooner.
alright np
In we landed a change to the Flow types in , making the types for the various types recursive with their and properties. On that PR we may have been running an older version of Flow - I'm not having luck finding the record of when Flow ran for that PR, so not sure. In any case, that PR was merged even though it had the recursive Flow type definitions, plus one or more Flow errors which were unrelated and not detected. The problem with the recursive type definitions is that recent versions of Flow will go into an infinite loop if they try to infer types which are recursive. The solution may be to add more detail to those types, but to unblock things we temporarily made them looser type definitions.
Appears to be working in Firefox but at least Chrome & Safari are broken. Should be a really recent regression so very few possible changes to blame... Easiest repo: the todo list on our homepage.
Just a heads up but this still seems to be an issue even on 15.4.1. I've been struggling to reproduce this because it seems to be some sort of ninja bug. Nevertheless, I was wondering if anyone is still dealing with this problem?
I haven't seen anything.
I'm still seeing this issue.
Please open a new issue with a simplified repro case if you're still seeing this!
Do you want to request a feature or report a bug? Report a bug What is the current behavior? The hook's value is shown as in React DevTools if the value is a string or a number. Clicking on the bug icon prints the correct values to console. ! If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. CodeSandbox: Direct link to page so you can see the DevTools: What is the expected behavior? The DevTools should show the correct value of the hook. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.9.0. Google Chrome [Version 77.0.3865.90 (Official Build) (64-bit)] running on Linux x64. This issue appeared after version 4.1.0 (9/19/2019) of the DevTools Chrome extension. Might be same bug as but this one appears without any complicated reproduction steps.
Looks like the issue also appears with boolean values.
Having the same problem. The extension worked fine after I downgraded React to version 16.8.6
I think the only significant difference between React v16.8 and v16.9 is that v16.9 injects the function DevTools uses to support editable hooks (in other words, DevTools is using a different code path when you run v16.8 vs v16.9). I think that means this bug is probably related to somehow. Will dig in more.
Should be fixed by
This fix will be released with 4.1.1 (sometime soon)
This fix has just been published to NPM and posted to Chrome/Firefox as v4.1.1
Since upgrading from beta3 to rc1 I've seen this error a few times in production. Haven't been able to trace the source yet though. cc
I was unmounting a root during a keyboard event which caused this to happen. I think this has always been a problem? Perhaps we've only been lucky... leaving open just to be sure. EDIT: Could it make sense to have something along the lines of ? Allowing you to schedule things to occur as soon as the current transaction ends.
This invariant was new in this release. We also hit one case at FB that I haven't yet investigated. Probably need to change something for the final release.
I have seen this on RC1 can't find a sequence of actions to repeat it.
I'm running into this issue as well when conditionally rendering based on state. Not sure how to boil it down to a simple reproducible bug report yet.
My issue only happens when I am leveraging FastClick. Didn't happen before 0.14.
I've found it is because the events are handled in a different order with fastclick, so the batching gets weird...
e.g. click gets fired before touchEnd, so click handler setState to remove subtree, and then react tries to do something with it in touch end perhaps?
In this repro, I created 2 buttons and only one is rendered at a time. One button's click handler is hooked up to React's synthetic "click" event while the other is hooked up to the native "click" event. Even though only one button is rendered at a time, a single click is triggering both click events. This bug can be hit by apps that mix React components with non-React controls (e.g. jQuery UI). I reproed this in Chrome with React 0.13.2. to the button labeled "One" Expected: There's a button rendered labeled "Two" Actual: The rendered button still has the label "One" If you open the console, you'll see "goToTwo" and "goToOne" which indicates that the "One" button's click handler ran and then the "Two" button's click handler ran (even though we never saw button "Two"").
I experimented more and came up with another repro: In this one, you click on a button with a native "click" handler which causes the button to go away and an input field to be rendered. It results in this exception: From these 2 repros, it seems something strange is going on when calling from within a native "click" handler.
It works if you add to the event handler.
Thanks for the workaround. Is the behavior without the by design? It looks like the bad behavior is being caused by the rerender happening synchronously within the native "click" handler.
This looks bad. We don't do a great job interacting with native events. Sebastian wrote a post about this once-upon-a-time, how native and synthetic event systems are, by and large, not interoperable. Even so, I can't see a reason we should fatal like this. Do you understand what's going wrong here? What a fix might look like?
This happens when we handle a click event from a node that's been removed in between when the event is triggered and when React receives it. How should we deal with the case that events fire on detached elements? Should we ignore events for nodes that aren't in the document? I don't think the bug is easily fixable otherwise because we don't have the old event handler after the reconcile that removes that node.
Here are some additional details about the impact of the bug.
It sounds like this bug is likely to trigger when you use a non-React component (e.g. jQuery UI) in a React single page application and the non-React component triggers a navigation within the app.
Thanks for an excellent bug report and good repro case! I think this happens because we use the "root id" to determine which element was clicked. In the repro case there is no "key" as part of the root ID for two reasons: 1) It is not a child of a container (multichild) so it doesn't get a key to the root ID. 2) It doesn't have a unique key and doesn't need one because it the button is of a different type. If I make sure that a key is used as part of the root ID the problem is solved: So the problem in the repro isn't that we're firing on a removed node, it is that we're firing the event on the new node. This would be solved if we used a unique ID per instance to identify event handlers instead of a generate root that is non-unique. Which I think we wanted to do anyway. Is there another repro that shows a different issue?
Since copy+pasting our code makes it too easy for people to XSS themselves, lets just add a comment in there about it.
PR at - let me know if that's what you had in mind!
My intuition is that it makes more sense to fix the example (call a sanitization library) or to change the example completely (demonstrate something else that is safer). It looks really bad to have a security warning on the homepage of the react site. Makes it seem like our framework encourages unsafe operations, rather than a safe-by-default way of doing things.
Should switch the demo to use a different library like markdown-js that escapes everything and doesn't support HTML:
markdown-js looks good. First attempt: ,output Code licensed if someone wants to turn this into a coherent example; I've signed the CLA.
That's a good suggestion too :) - what are your thoughts? I'm happy to change the example to use like people have suggested above. nice usage example :+1:
Uh yea, that sounds fine to me. This behavior is definitely non-standard markdown but it's an example so not a big deal. We should probably do the same for the tutorial while we're here. And it's on cdnjs so that's all pretty easy:
Just going to use marked instead, which I'm already familiar with and has an option to sanitize input.
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React Dev Tools version: 4.6.0 I'm not sure there is a problem with within package, or it's just my misunderstand how it works, but script create production build. Command above runs a each script (per browser) in which is set to . run in creates minified version of files. where has set to . Each step in should be replaced from to
Send a PR? This does look odd.
Sure, I'll take a look at it tomorrow, it's looks odd and incorrectly but need to check there isn't any trap with that
There appears to have been a change in how is generated between 0.13 and 0.14 which is causing a number of our shallow rendered tests to fail when upgrading because the deepEquals fails on the property. Here is a simple example component which exhibits the issue.
I've been seeing some similar issues with shallow rendering. My current (messy - sorry!) workaround is this: Let me know if that helps! My version currently breaks some of the Jest tests, but I'm happy to work on this some more and submit a PR.
Thank you very much for this, it's been a tremendous help! While this solved the problem for my test case above it still failed on a large number of our more complex tests. I've been iterating on it and once I have all of our tests passing I'll add the updated version.
Here is the updated workaround, it works for our 238 tests of varying complexity but I'd be interested to see if it passes all of your tests as well.
Awesome! If you don't mind trying, what happens if you do and then use the earlier ?
Much cleaner thanks, I guess I was in my head too much :)
I prefer applying a monkey patch, until we have this fixed in react by wrapping TestUtils in my own module:
This should be fixed by .
<!-- Please answer both questions below before submitting this issue. --Please provide a link to the URL of the website (if it is public), a CodeSandbox () example that reproduces the bug, or a project on GitHub that we can checkout and run locally. If possible, please describe how to reproduce this bug on the website or app mentioned above: <!-- FILL THIS IN --<!-- FILL THIS IN --<!-- FILL THIS IN --<!---------------------------------------------------<!-- Please do not remove the text below this line --<!---------------------------------------------------DevTools version: 4.13.1- Call stack: at chrome- at (chrome-) at chrome- at listener (chrome-) Component stack: (none) GitHub URL search query:
Hi I'm sorry you ran into this problem Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce it though. This means that it's going to be very hard for us to fix. Please help us by providing a link to a CodeSandbox (), a repository on GitHub, or a minimal code example that reproduces the problem. (Screenshots or videos can also be helpful if they help provide context on how to repro the bug.) Here are some tips for providing a minimal example:
I am also having this bug
See the comment above please :) Repro is needed.
This happened to me, the node wasn't appearing in the Components tree and I was getting this error. The problem was that my attribute was way too long
! suddenly having this issue right now. I thought it was because of my commits, but changing to another old branch just give the same errors. it was working just fine yesterday, don't know why. maybe due to the devtools update or something? btw I'm on react 16.8.6, react devtools 4.13.3 (5/19/2021)
Try updating to the latest release (4.13.4) just to rule anything out. But if you're still seeing the issue, then we still need a repro case.
at first the bug still persists. with same error log. then I retried close the devtools and opened it again (I think I actually have done this as well before) then somehow it works now. the error log still shows up but at least now all components are showing on the devtools, and that's all I need.
in addition, I found this ! and I was trying to hide that component (which has no recent changes on it) to see whether it has any impact. or any component that last showing on the devtools. but for now, that'll be all. thank you for responding
I appreciate the extra information, but this isn't a description that I can use to reproduce (and fix) the bug. I need an actual website (or code) that I can run along with instructions (like "do this, then this") so I can see the bug.
There are some simple code could help reproduce. You could try following code sandbox link. The reproduce steps are: "Do not" open develop panel. to develop panel and go to react dev tab. Errors was shown. I guess it's kind of race condition. When I change the component order such as It will work perfect. Ps: brief explain what component do. The PageLoadProgressHandler will dispatch float element to PopupPool.
Excellent! Thank you, Super interesting that this bug only occurs if you wait to open DevTools until after the page has loaded.
I think it is because only have two components, I have two sites, one it will always happen, another will random happen. or maybe code-sandbox do some strange things.
This is interesting. The reason DevTools throws is that the Fiber's owner (the attribute) points to a Fiber that hasn't been mounted yet. That seems unexpected. This repro is just a wrapper around two NPM packages. Where's the source code for these packages? :D Edit I found it, although there's a lot of indirection here_. Tracing one package which imports another which imports another. Would be helpful if it were flattened but I guess I can always step through the bundled source.
PopupPool: PageLoadProgressHandler: Good luck... XD.
Interestingly, if I copy the , , and source files into the sandbox (and only change the import statement in ) the bug goes away. That's surprising.
I wonder if I'm running slightly different code? The debug log shows a slightly different tree structure.
Is the version of the source you linked me to the same as the one the Sandbox points to in NPM, Edit Looks like the repro is using 0.18.8 (released a couple of months ago) but the latest NPM release is 0.11.1. That being said, it doesn't look like the files that are being imported have changed (at least not in source) so I'm still not sure what's up.
I change two main components to hook style then get better performance, it reduce the error happen, but I still could get error. Some error is happen after component render done and open the panel same behavior with pervious. I'll log my changes in following issue ticket.
Would be nice to get a smaller reproduction of this issue (all of the code in one project, rather than spread across many NPM packages). That's what I was trying to do with moving the source but then the bug goes away b'c the code seems to be different. I noticed one potential difference being the indirection but I'm not sure how likely that is to be related.
Looking at the error while debugging, it looks like the , then either renders it or dispatches a popup event to show it. I'm not sure why (too sleepy to think it through maybe) but sometimes seems to be mounting before_ has, which goes against an assumption in DevTools. Will dig back in tomorrow.
I really appreciate the repro case, but there are so many layers of indirection between the various NPM packages being used to dynamically create the components. It's difficult to trace through. I'm going to hand this issue to you and ask for a smaller repro case. (Without 10+ NPM projects that each require each other.) Is this something you can help with? Edit I fixed this () but the test case I is not great since it relies on unsupported side effects to trigger the problem case. I'd still love to get a smaller repro so I can (1) be sure I fully fixed the problem and (2) add a regression case so it doesn't get re-introduced.
Bugfix released as
thank you fixed on version 4.13.5
Thanks your effort. Your fixed also be success from my side.
Follow up from Here's one I found. These two invariants: are in a function that's behind a DEV block: I don't think this is intentional, but need to verify. There may be more. I'll use this issue to track while preserves existing behavior.
Here’s another difference: in development, putting a string ref on a functional component throws with: Stateless function components cannot have refs. but in production gives you: Element ref was specified as a string but no owner was set.
After updating react-dom to version 17 the build now includes () which isn't supported by ie11 without polyfilling. Coming from this line. Tested with just the default cra production build to make sure it wasn't a problem with my webpack config and the same issue. Tested using CRA on version 16.9.8 of react and react-dom which works with the production build for ie11.
Confirmed with https://csb-hznfc- (built from ) which errors with "SCRIPT438: Object doesn't support property or method 'fill'".
Any chance you could confirm the fix on a real IE
Gonna wait to see if a few more bugs get reported in the next few hours. Then will cut a patch.
Should be fixed in 17.0.1.
I a "bug" today that made me spent 1h figuring out what was going on: I'm using an external component that accepts a prop in order to set the of the root element, but this same component also accepts a prop which I wasn't passing, and by default, it was set to . The result: React didn't throw an error nor a warning, however, the resulting element in the DOM didn't contain either or , and since the element had a default coming from a CSS class, it took me a while to figure out why the color that I was passing wasn't being applied, and instead it was using the one from the CSS class. See: What I reported above was the case. I other cases as a bonus, as when I was playing with this they also seemed weird to me. On I define the same properties, but because I change the order, it works. On the toggleable ones, initially I can see the background, but after changing it never appears anymore. I'm not sure if I created those extra "test cases" correctly. My main concern is really around static1 not outputting anything on the console as a warning. Related issues: I wonder if ( should have covered this?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
it seems that the bot automatically closed the issue, but this still needs action. I took a time to investigate it, and I realized that the work Sophie has done covers this case, but there's just one problem: it's disabled under a . I built it locally and flipped the flag, and it works: I can see the helpful warning. It was flagged in , and as per the PR, the original intention was to unflag it on the next minor. Since then we had at least 4 new minor versions, but it is still flagged. Is there a special reason for that or was it just forgotten? tagging you since you this flag, so I'm hoping you can give context here.
Can we unflag this?
This was released.