-
Notifications
You must be signed in to change notification settings - Fork 138
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
Add delay at the end of the redux-fundamentals e2e example #10341
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -140,4 +140,6 @@ export default async function testFunction( | |||
|
|||
await filtersPanel.getByText('Green').click() | |||
await waitForListItemsCount(2) | |||
|
|||
await delay(500); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR doesn't explain the "why" for this change. Why is this necessary? Why wouldn't it be better for us to wait on something specific rather than a seemingly arbitrary number of milliseconds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing Linkage
What I always do is:
- I link the Linear issue, and specifically a final
SLN
comment under that issue that explains the rationale behind a change. In this case, the rationale is also exlpained in the issue, but its not linked directly. Having that direct link makes things a lot easier! - If a change is a hackfix for an issue, I always add the issue number as a comment to the hackfix in the code.
To answer your question
TL;DR: This is to paper over what we believe to be an outstanding (and very hard-to-fix) runtime issue RUN-3258.
Ref: here is the link 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hbenl If that's what this is for it would be nice to have a comment linking it to that issue. (If I saw this, a random delay at the end of a test, I would assume it was left over from a previous refactor and fair game to delete.)
No description provided.