fix: turn-off-heartbeat-flooding-if-required #268
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Apr 4, 2025
cdc0d4e to
8d4f0d8
Compare
18b6048 to
62483f8
Compare
sarahsimionescu
approved these changes
Apr 6, 2025
| AWS_REGION=your_region | ||
|
|
||
| # Usefull for debugging. If you set to =false, then any failure in the heartbeat ping will not be logged. | ||
| HEARTBEAT_DEBUG=true |
There was a problem hiding this comment.
[suggestion] set to false by default
Merge activity
|
liongyeehong
pushed a commit
to Xxell-Ai/meetingbot
that referenced
this pull request
Sep 15, 2025
### TL;DR Added a HEARTBEAT_DEBUG environment variable to control heartbeat error logging -- stops flooding the terminal with 'heartbeat could not send' error if the backend is not online. ### What changed? - Added a new `HEARTBEAT_DEBUG` environment variable in `.env.example` with a default value of `true` - Modified the heartbeat error handling in `monitoring.ts` to only log errors when `HEARTBEAT_DEBUG` is not explicitly set to `false` - Added a comment explaining the purpose of the new environment variable ### How to test? 1. Copy the new `HEARTBEAT_DEBUG` variable to your `.env` file 2. Set `HEARTBEAT_DEBUG=false` to suppress heartbeat error logs 3. Set `HEARTBEAT_DEBUG=true` or leave it unset to see heartbeat error logs 4. Trigger a heartbeat error (e.g., by disconnecting from the network) to verify the logging behavior ### Why make this change? This change allows developers to suppress heartbeat error logs during local development, which can be noisy and distracting when working in an environment where heartbeat failures are expected or irrelevant. The default behavior remains unchanged (errors are logged), but developers now have the option to disable this logging when needed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR
Added a HEARTBEAT_DEBUG environment variable to control heartbeat error logging -- stops flooding the terminal with 'heartbeat could not send' error if the backend is not online.
What changed?
HEARTBEAT_DEBUGenvironment variable in.env.examplewith a default value oftruemonitoring.tsto only log errors whenHEARTBEAT_DEBUGis not explicitly set tofalseHow to test?
HEARTBEAT_DEBUGvariable to your.envfileHEARTBEAT_DEBUG=falseto suppress heartbeat error logsHEARTBEAT_DEBUG=trueor leave it unset to see heartbeat error logsWhy make this change?
This change allows developers to suppress heartbeat error logs during local development, which can be noisy and distracting when working in an environment where heartbeat failures are expected or irrelevant. The default behavior remains unchanged (errors are logged), but developers now have the option to disable this logging when needed.