-
Notifications
You must be signed in to change notification settings - Fork 90
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
Makefile: Update Cockpit lib to 79623a0a425600da302f66a2752afe35 #1832
Makefile: Update Cockpit lib to 79623a0a425600da302f66a2752afe35 #1832
Conversation
607c53f
to
756712c
Compare
756712c
to
8af4036
Compare
The issue is the click in Firefox now clicks in the middle of the CPU Shares NumberInput which doesn't trigger the checkbox to get checked. This is a bug in PF, so we work around here by clicking on the left button. Maybe a better solution is:
|
Locally I get:
Don't see this in CI, but it is 💯 reproducible locally. |
These tests are wonky with Chromium as well, but for different reasons. I can reproduce the latter locally (although with Firefox) -- the dialog's primary button just does not want to become active, even though there are no validation errors. This reproduces 100% for me, and it fails earlier than @jelly 's error above, so I suppose I need to fix that first before I can investigate that. (Firefox failed on TF the same way). This is an actual real bug -- even interactively I can't seem to get the "Create" button to enable itself, even after wildly clicking and tabbing around, changing the name, or deleting port and volume mappings. I manually did a firefox run on our infra and that succeeded -- so these are race conditions, no hard errors.
@jelly The "Decrease CPU shares" thing is curious -- CPU shares is disabled by default, so I originally thought it meant to click the checkbox, not the Minus button in the shares value selector. A few lines down it changes the shares to "512", so I don't think it meant to decrease it to 1023. However, the comment says "checkbox is enabled when clicked on the field", so I suppose it's indeed meant to work like that. So your fix is correct. I split it out into a separate commit with some details. I can locally reproduce the testCreateContainerInPodUser "out of bounds" error. Observations:
But I just realized what happens: The dialog defaults to "All", and the busybox image is also displayed there. We click on "Local", but there's nothing that waits for the "new" test-busybox render to happen -- the click could still try to go to the old one before it switches over to the "Local" view. That's why the sleep helps. |
8af4036
to
8f5354e
Compare
8f5354e
to
9c10378
Compare
9c10378
to
0879745
Compare
@jelly So aside from some minor flakes, the main bug is now that forever-disabled Create button in the pod dialog. That is 100% reliably reproducible for me with
and as I wrote above, neither a race condition, nor a quirk with clicks -- a human can't enable that "Create" button either. I figure this requires some console.log instrumentation why the button is disabled. Do you want to look into that? |
This testDownloadImage flake (on ubuntu as well) is also fairly persistent. Again, not related to clicking (happens on Chromium), and smells more like "missed podman event". Retrying these, in the meantime I run this in a loop locally to try and reproduce. |
Amplified createPod with debug logs:
Update: pitti also saw this in a different PR in testCreateContainerInPodSystem here Update: jelle sees more weird behaviour So the test first enters -1, waits for validation to appear and then removes the entry. Then add a new entry. Does the state not get cleaned up correctly? Locally I can reproduce something different but also wrong. Just create a pod, enter -1, click anywhere, validation does not change. Only when clicking This is an unrelated bug. |
Locally one can reproduce this: State being:
What I did was, add toy around with the state. Add one valid entry, add an empty, add another valid one, save. The invalid entries aren't cleaned up properly. Update: One way to mess things up good: Easy reproducer:
|
So I conclude that we are doing all the state interaction wrong with validation.. The PodCreateModal has a state
This component has
The value passed comes from PublishPort:
So this modifies React state and then passes it to onValidationChange which is also a same named function in DynamicListForm:
Modifies state again. This seems to be what causes all the inconsistent state issues
|
9a40eb2
to
e067438
Compare
#1834 landed, rebased to fix the conflict. |
e067438
to
ca72105
Compare
#1833 landed, pushed rebase to de-conflict. |
@martinpitt so this is looking good, do we naughty:
Or adjust the test? |
@jelly naughty works for now, if this is too hard to work around in the test; can you distill your analysis into an issue? Also, wasn't there another failure in |
Hmmm I didn't push a fix, the fix should be quite easy but it no longer reproduces? |
@jelly how about |
ca72105
to
0fe1841
Compare
Done, let's see if that helps enough. |
Sure! |
@jelly Hm, no, not sufficient: chromium runs into this as well |
Continued in #1842. |
Requirements/split out: