-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
migrate pid file to core #77037
migrate pid file to core #77037
Conversation
process.on('unhandledRejection', function (reason) { | ||
logger.warn(`Detected an unhandled Promise rejection.\n${reason}`); | ||
}); |
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 was in the legacy file, so I kept it for now, but I honestly have no idea why this was here.
This seems already handled by
kibana/src/setup_node_env/exit_on_warning.js
Lines 39 to 45 in bf04235
// While the above warning listener would also be called on | |
// unhandledRejection warnings, we can give a better error message if we | |
// handle them separately: | |
process.on('unhandledRejection', function (reason) { | |
console.error('Unhandled Promise rejection detected:'); | |
console.error(); | |
console.error(reason); |
@spalger Am I safe to remove this from this file?
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.
I wonder if this is here so that warnings are included in the standard kibana log, rather than only written to the console, once the logger is setup. That said, both of these listeners do seem to be setup. I'd ask @watson just to be sure though.
(sorry for the late handoff, was out last week)
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.
I must have missed the original unhandledRejection
listener from src/legacy/server/pid/index.js
when I implemented the one in src/setup_node_env/exit_on_warning.js
.
The intention with the src/setup_node_env/exit_on_warning.js
script is to exit on warnings during development and CI only. This way we catch these warnings as early as possible. It's all too easy to overlook them in the logs during development/CI, and so they slip into production builds. In production we normally run with the --no-warnings
flag, so none of the listeners in src/setup_node_env/exit_on_warning.js
are added in production.
So in production, the listener in this file is still active (though output depends on log-level). Whether or not we want this in production is a good question that I don't know the answer to. It's worth noting that Node.js it self will output the following to STDERR in case there's no unhandledRejection
listener:
(node:88082) UnhandledPromiseRejectionWarning: undefined
(node:88082) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:88082) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
So adding the listener in this file means that we'll suppress that default behaviour even if log-level is set below warning
.
Side note: Starting in Node.js 15, the process will crash by default if an unhandledRejection
happens, but we'll not be affected by this until we upgrade to Node.js 16 as we'll skip 15.
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.
Thanks for the answer. To avoid changing the behavior that was present in legacy, I will keep this now.
Pinging @elastic/kibana-platform (Team:Platform) |
|
||
await writeFile(path, pid); | ||
|
||
logger.info(`wrote pid file to ${path}`, { path, pid }); |
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.
It used to have debug
level
expect(writeFile).toHaveBeenCalledWith('/pid-file', pid); | ||
|
||
expect(process.once).toHaveBeenCalledTimes(2); | ||
expect(process.once).toHaveBeenCalledWith('exit', expect.any(Function)); |
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.
I guess it's not worth the effort to test process.exit
& SIGINT
, so that is ok
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.
LGTM.
On the non-issue side - do you know where this lives in the setup lifecycle? I've been a little iffy on the (legacy) current implementation - similar to the logger, this feels like a bootstrap/setup_node_env type task that has the most utility when setup ASAP before the platform starts. e.g. the longer it takes for this file to write the less it can be used rely on process monitoring.
I haven't seen any issues opened because of it, so np. Feel free to ignore and we can revisit if issues do come up.
The kibana/src/core/server/server.ts Lines 107 to 110 in a19484a
it's still in the server initialization, not in |
Yeah no problem, I'm okay with delaying on the issue too. I'm half curious to see if we ever get a production type issue filed for it. It doesn't seem to be impacting anyone so far. |
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.
Changes regarding unhandledRejection
handler LGTM 👍
💚 Build SucceededBuild metricsdistributable file count
History
To update your PR or re-run it, just comment with: |
* migrate pid file to core * use correct log level + add comment * move `unhandledRejection` to service's setup * update comment
Summary
Fix #77019
Checklist