Does not shutdown completely when run from the CLI #104

ajotaos · 2020-11-06T18:26:38Z

After running tsc-watch, on its own, from the CLI and trying to stop it, I'm always requiring an additional Ctrl+C.

Also, when used alongside concurrently, the SIGINT and SIGTERM is not being passed to the code in the onSuccess argument.

How do I tell tsc-watch, when run from the CLI, it should end the process and not remain hanging?

The text was updated successfully, but these errors were encountered:

gilamran · 2020-11-07T12:16:21Z

That's interesting, as I encountered the same issue (Ctrl-C). never thought that the cause is tsc-watch.
But do you think that the SIGINT and SIGTERM is the same issue?

Can you organize a simple example repo to reproduce?

Thanks

ajotaos · 2020-11-07T13:33:28Z

Sure @gilamran

I really think tsc-watch is the responsible for the Ctrl+C. If you were to run tsc --watch and exit with Ctrl+C everything is fine but tsc-watch gets hold up. I'm using tsc --watch as reference since it mentions in the documentation that it's being used underneath.

You can test this separately with npm run watch:ts (tsc-watch hangs) and npm run watch:tsc (tsc --watch exits) or together with npm run watch:*. No matter how you run it or if you add more tasks, watch:ts is always the last one to log and remains exiting forever.

Not always do the SIGINT and SIGTERM handlers are called, it looks random but maybe there's something.

src/index.ts

console.log(`Script has started`);

const intervalId = setInterval(() => {
  console.log('tick');
}, 1000);

process.on('SIGINT', () => {
  clearInterval(intervalId);
  console.log(`Script has ended`);
  process.exit();
});

process.on('SIGTERM', () => {
  clearInterval(intervalId);
  console.log(`Script has ended`);
  process.exit();
});

tsconfig.json

{
  "compilerOptions": {
    "incremental": true,
    "target": "ES2020",
    "module": "CommonJS",
    "strict": true,
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "rootDir": "./src",
    "outDir": "./dist",
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["./src/**/*"],
  "exclude": ["./node_modules"]
}

package.json

{
  "scripts": {
    "start": "concurrently --kill-others yarn:watch:*",
    "watch:ts": "tsc-watch --onSuccess \"node ./dist\" --noClear",
    "watch:tsc": "tsc --watch"
  },
  "dependencies": {},
  "devDependencies": {
    "concurrently": "5.3.0",
    "tsc-watch": "4.2.9",
    "typescript": "4.0.5"
  }
}

ajotaos · 2020-11-07T18:13:38Z

I have been continuing playing with it and sometimes even though I Ctrl+C it, the process has not been killed.

gilamran · 2020-11-07T20:19:55Z

Thanks! I'll look into it.

gilamran · 2020-11-09T10:48:19Z

I did a test (using your example code) and the Ctrl-C did terminate the process (Using SIGINT).
I'm using Mac. What's your OS?

ajotaos · 2020-11-09T11:59:21Z

I'm on Catalina 10..15.7 (the latest one), node 15.1.0, typescript 4.0.5 and tsc-watch 4.2.9.

When running watch:ts it's more subtle, there are hints for example, after Ctrl+C and the line prompt appearing on the terminal that if you push the up arrow button, instead of brining the previous like it will print ^[OA which happens when there's a process running.

It's more noticeable on the start script. In this case it happens the same as previously but the line prompt will not appear.

gilamran · 2020-11-09T12:25:37Z

I'm using the exact same versions, and Ctrl-C just stops the process... I don't see what you're describing...
What am I missing?

ajotaos · 2020-11-09T12:30:03Z

Does it work for you to video chat it on Zoom to check it out live?

gilamran · 2020-11-09T13:51:53Z

how can we do a private chat?

ajotaos · 2020-11-09T13:54:12Z

On GitHub? I didn't know it has that feature.

gilamran · 2020-11-09T13:54:40Z

I see that you're online... lets do zoom now

gilamran · 2020-11-09T13:55:48Z

https://zoom.us/j/93636684173?pwd=Qlh2RGExTFVoK3JsY25ZQm1GaGg3QT09

ajotaos · 2020-11-09T13:58:02Z

I'm in @gilamran

ajotaos · 2020-11-09T14:20:38Z

Ok, after the Zoom meeting, it appears this issue is occurring only with the Yarn package runner. NPM works fine.

gilamran · 2020-11-09T14:59:05Z

I've pushed a branch test-kill please try it.

ajotaos · 2020-11-09T15:34:06Z

It worked on the single script watch:ts. The concurrently one start still requires a second Ctrl+C using yarn, on npm it works.

jackHedaya · 2021-01-11T15:18:02Z

I'm experiencing this issue as well, is there a patch?

ibash · 2021-02-19T09:47:20Z

Took a peek based on @ajotaos's comment, haven't attempted any fixes:

npm forwards sigint and sigterm: https://github.com/npm/cli/blob/e703362b02d672a14a98af8e2f99ae75c1bab945/node_modules/%40npmcli/run-script/lib/signal-manager.js#L4
yarn only forwards sigterm: https://github.com/yarnpkg/yarn/blob/a4708b29ac74df97bac45365cba4f1d62537ceb7/src/util/signal-handler.js#L11
concurrently has special handling for sigint: https://github.com/kimmobrunfeldt/concurrently/blob/b62a2a1c92caa590b78f336cc8fcef745e5a7832/src/flow-control/kill-on-signal.js#L20

hamzadigi · 2021-11-11T01:31:58Z

Having similar issue when ctrl + c with yarn

divmgl · 2023-07-28T19:00:39Z

We've had to move away from tsc-watch due to the number of loose process issues where exiting the process doesn't kill the running subprocess, so we have to manually kill the port after the fact. Also it sometimes just stops compiling at all.

gilamran · 2023-07-30T17:00:21Z

I've very sorry to hear that, maybe you can provide an example to reproduce the issue?

Mujo · 2023-08-14T20:25:46Z

We've had to move away from tsc-watch due to the number of loose process issues where exiting the process doesn't kill the running subprocess, so we have to manually kill the port after the fact. Also it sometimes just stops compiling at all.

same problem here.
when vscode is on Auto Attach mode with auto save, or using a debug terminal, each change on the file open a new debug process but don't close the previous one when using the --onSuccess with "npm start" or "node ./outDir".

gilamran · 2023-08-14T20:29:36Z

@Mujo I'm sorry but I don't understand your reproduction steps... can you give me clear instructions on how to reproduce this?

Mujo · 2023-08-14T20:47:09Z

Looks like something in most of the projects we use here in work is holding the process.
I tried to create a new project but couldn't reproduce yet. when i find it i will post here again.

vimtor · 2024-03-26T10:41:43Z

I'm facing the same issue using Turborepo.

divmgl · 2024-03-26T13:17:31Z

Hey all, tsx does not have any of these issues. It also has a watch mode. https://github.com/privatenumber/tsx

gilamran · 2024-03-26T15:41:05Z

Is anyone can provide a simple reproduction repo.?

acaumartin-cameleon · 2024-07-18T15:04:28Z

Hi,

I can't provide a simple reproduction repo right now, but I think you can reproduce the problem by loading a couple queue system. I think they launch subprocess to run and I think they are not close properly on the reload.

The project I'm working use Pubsub and bullmq to handle messaging and task.

You could try to run a project that run a lot of bullmq worker (I guess more than 10 should do it).

irahopkinson · 2024-10-22T02:38:47Z

Hey all, tsx does not have any of these issues. It also has a watch mode. https://github.com/privatenumber/tsx

Actually tsx has this problem in watch mode tsx watch (see privatenumber/tsx#163).

msyahidin · 2025-02-23T07:37:11Z

Is there any update on this issue?

gilamran · 2025-02-23T10:00:43Z

Is there any update on this issue?

Do you have a simple way to reproduce this issue?
So far, we know that it happens only on yarn

msyahidin · 2025-02-23T14:52:13Z

@gilamran I don't know if this will help or not, this is the npm script I used. I am using this boilerplate for my project
I will help to simply reproduce when I have time,

execute npm run start:dev
app started
hit API request
editing code
editing code
hit API request -> get response from app (expected)
CTRL + C
terminal shows like the app stop
hit API request -> get response from app (unexpected)
terminal shows logging get request (unexpected)

"start": "ts-node -r tsconfig-paths/register src/main.ts",
"start:dev": "npm run copy:asset && tsc-watch -p tsconfig.build.json --onCompilationComplete \"tsc-alias -p tsconfig.build.json\" --onSuccess \"node dist/src/main.js\"",
"start:staging": "npm run copy:asset && tsc-watch -p tsconfig.build.json --onCompilationComplete \"tsc-alias -p tsconfig.build.json\" --onSuccess \"node dist/src/main.js\"",
"start:debug": "npm run copy:asset && tsc-watch -p tsconfig.build.json --onCompilationComplete \"tsc-alias -p tsconfig.build.json\" --onSuccess \"node --inspect-brk dist/src/main.js\"",

gilamran · 2025-02-23T15:02:32Z

Why are you editing code twice? is that relevant? does that include a save that will trigger a restart?
What's "hit API request"? you are calling a remote API from your server?
Sorry but I need a more detailed reproduction...

gilamran · 2025-02-23T16:46:37Z

I did some tests again, on my (Windows) machine and Ctrl-C terminates the processes.
I tried using concurrently, with and without tsc-watch, all working.
If anyone is willing to create a simple repo. with an example of this issue, I'll fix this.

msyahidin · 2025-02-25T13:50:58Z

Why are you editing code twice? is that relevant? does that include a save that will trigger a restart? What's "hit API request"? you are calling a remote API from your server? Sorry but I need a more detailed reproduction...

@gilamran Hi thanks for testing it again. I edited twice which means, I edited in different lines or pages.

Anyway, I think I found the root cause and solved my problem. My issue is not from tsc watch, but from nestsjs configuration when handling multiple database connections.
The details in here typeorm/typeorm#9672 , the logs did not show every time, so I think false alarm

TLDR
The error

UnknownElementException [Error]: Nest could not find DataSource element (this provider does not exist in the current context)
    at InstanceLinksHost.get ([path]/node_modules/@nestjs/core/injector/instance-links-host.js:24:19)
    at ModuleRef.find ([path]/node_modules/@nestjs/core/injector/abstract-instance-resolver.js:8:60)
    at ModuleRef.get ([path]/node_modules/@nestjs/core/injector/module.js:349:28)
    at TypeOrmCoreModule.<anonymous> ([path]/node_modules/@nestjs/typeorm/dist/typeorm-core.module.js:117:47)
    at Generator.next (<anonymous>)
    at [path]/node_modules/@nestjs/typeorm/dist/typeorm-core.module.js:20:71
    at new Promise (<anonymous>)
    at __awaiter ([path]/node_modules/@nestjs/typeorm/dist/typeorm-core.module.js:16:12)
    at TypeOrmCoreModule.onApplicationShutdown ([path]/node_modules/@nestjs/typeorm/dist/typeorm-core.module.js:116:16)
    at callAppShutdownHook ([path]/node_modules/@nestjs/core/hooks/on-app-shutdown.hook.js:51:35)

The Fix

TypeOrmModule.forRootAsync({
	imports: [],
	name: 'secondary', // this
	useFactory: () => ({
		...anything,
		name: 'secondary' // this
	})
});

Does not shutdown completely when run from the CLI #104

Does not shutdown completely when run from the CLI #104

Comments

ajotaos commented Nov 6, 2020 • edited Loading

gilamran commented Nov 7, 2020 • edited Loading

ajotaos commented Nov 7, 2020 • edited Loading

ajotaos commented Nov 7, 2020

gilamran commented Nov 7, 2020

gilamran commented Nov 9, 2020

ajotaos commented Nov 9, 2020

gilamran commented Nov 9, 2020

ajotaos commented Nov 9, 2020

gilamran commented Nov 9, 2020

ajotaos commented Nov 9, 2020

gilamran commented Nov 9, 2020

gilamran commented Nov 9, 2020

ajotaos commented Nov 9, 2020 • edited Loading

ajotaos commented Nov 9, 2020

gilamran commented Nov 9, 2020

ajotaos commented Nov 9, 2020 • edited Loading

jackHedaya commented Jan 11, 2021 • edited Loading

ibash commented Feb 19, 2021

hamzadigi commented Nov 11, 2021 • edited Loading

divmgl commented Jul 28, 2023

gilamran commented Jul 30, 2023

Mujo commented Aug 14, 2023 • edited Loading

gilamran commented Aug 14, 2023

Mujo commented Aug 14, 2023 • edited Loading

vimtor commented Mar 26, 2024

divmgl commented Mar 26, 2024

gilamran commented Mar 26, 2024

acaumartin-cameleon commented Jul 18, 2024

irahopkinson commented Oct 22, 2024

msyahidin commented Feb 23, 2025

gilamran commented Feb 23, 2025

msyahidin commented Feb 23, 2025

gilamran commented Feb 23, 2025

gilamran commented Feb 23, 2025

msyahidin commented Feb 25, 2025

ajotaos commented Nov 6, 2020 •

edited

Loading

gilamran commented Nov 7, 2020 •

edited

Loading

ajotaos commented Nov 7, 2020 •

edited

Loading

ajotaos commented Nov 9, 2020 •

edited

Loading

ajotaos commented Nov 9, 2020 •

edited

Loading

jackHedaya commented Jan 11, 2021 •

edited

Loading

hamzadigi commented Nov 11, 2021 •

edited

Loading

Mujo commented Aug 14, 2023 •

edited

Loading

Mujo commented Aug 14, 2023 •

edited

Loading