Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Error when running ctrl-c in dev mode #375

Closed
Electroid opened this issue Feb 2, 2022 · 2 comments · Fixed by #732 or #721
Closed

Error when running ctrl-c in dev mode #375

Electroid opened this issue Feb 2, 2022 · 2 comments · Fixed by #732 or #721
Assignees
@JacobMGEvans

Comments

@Electroid
Copy link
Contributor

What version of Wrangler are you using?

0.0.0-b8e3b01 (alpha)

What operating system are you using?

Mac

Describe the Bug

The following error occurs when running ctrl-c when wrangler dev is active. Sometimes the errors appears, but sometimes it does not.

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.
    at Remote (/.../node_modules/wrangler/wrangler-dist/cli.js:113212:42)
    at Dev (/.../node_modules/wrangler/wrangler-dist/cli.js:113160:13)
    at ErrorBoundary2 (/.../node_modules/wrangler/wrangler-dist/cli.js:92101:39)
    at withErrorBoundary(Dev)
    at App (/.../node_modules/wrangler/wrangler-dist/cli.js:76011:9)
@Electroid Electroid added the bug label Feb 2, 2022
@threepointone
Copy link
Contributor

I'll assign this to myself, I understand what's going on here and the fix is a bit involved.

@threepointone threepointone self-assigned this Feb 2, 2022
@petebacondarwin petebacondarwin added this to the 2.0 milestone Feb 3, 2022
@Electroid Electroid mentioned this issue Feb 4, 2022
Closed
@Electroid Electroid moved this to Non-blocking in workers-sdk Feb 7, 2022
@threepointone
Copy link
Contributor

Unassigning myself, anyone else can take this if they'd like, or I can come back to it later

@threepointone threepointone removed their assignment Feb 7, 2022
@JacobMGEvans JacobMGEvans self-assigned this Mar 25, 2022
@JacobMGEvans JacobMGEvans mentioned this issue Mar 29, 2022
Closed
JacobMGEvans added a commit that referenced this issue Mar 30, 2022
@JacobMGEvans
Adding abort to the waitForPortToBeAvailable as an option and in th…
89b464c 
…e `useEffect` the abort signal is called in the return which allows for graceful closing with no hanging

of the `waitForPortToBeAvailable`

fixes #375
@JacobMGEvans JacobMGEvans mentioned this issue Mar 30, 2022
Merged
JacobMGEvans added a commit that referenced this issue Mar 31, 2022
@JacobMGEvans
Adding abort to the waitForPortToBeAvailable as an option and in th…
c0eba4c 
…e `useEffect` the abort signal is called in the return which allows for graceful closing with no hanging

of the `waitForPortToBeAvailable`

fixes #375
@petebacondarwin petebacondarwin moved this from Should-have to In Review in workers-sdk Apr 1, 2022
JacobMGEvans added a commit that referenced this issue Apr 4, 2022
@JacobMGEvans
Adding abort to the waitForPortToBeAvailable as an option and in th…
53d0589 
…e `useEffect` the abort signal is called in the return which allows for graceful closing with no hanging

of the `waitForPortToBeAvailable`

fixes #375
JacobMGEvans added a commit that referenced this issue Apr 4, 2022
@JacobMGEvans
Adding abort to the waitForPortToBeAvailable as an option and in th…
89edf75 
…e `useEffect` the abort signal is called in the return which allows for graceful closing with no hanging

of the `waitForPortToBeAvailable`

fixes #375
JacobMGEvans added a commit that referenced this issue Apr 4, 2022
@JacobMGEvans @petebacondarwin
Abort signalling (#732)
c63ea3d 
* fix: abort some of the fetches when we unmount the `Remote` component

* Adding abort to the `waitForPortToBeAvailable` as an option and in the `useEffect` the abort signal is called in the return which allows for graceful closing with no hanging
of the `waitForPortToBeAvailable`

fixes #375

Co-authored-by: Pete Bacon Darwin <pete@bacondarwin.com>
Repository owner moved this from In Review to Done in workers-sdk Apr 4, 2022
@github-actions github-actions bot mentioned this issue Apr 4, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@JacobMGEvans JacobMGEvans

Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@petebacondarwin @threepointone @Electroid @JacobMGEvans