-
Notifications
You must be signed in to change notification settings - Fork 33
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
Ensure instances are started after creation even with long running create processes WD-4050 #360
Conversation
Demo starting at https://lxd-ui-360.demos.haus |
}; | ||
ws.onmessage = (message: MessageEvent<Blob | string | null>) => { | ||
if (typeof message.data !== "string") { | ||
console.log("Invalid format on event api: ", message.data); |
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.
console.log("Invalid format on event api: ", message.data); | |
// TODO: remove this and other console.log calls | |
console.log("Invalid format on event api: ", message.data); |
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.
The log is for discovery of errors in the future. I wouldn't want to remove this in the future. I see we added this todo comment to various places where we handle websockets and think it should be removed there as well. Or how would this be useful?
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 don't understand what's special about websockets to justify these calls to console.log
, which are discouraged for production code and a bad practice in general. They leak information about the app to the user.
Also, we don't apply the same error logging logic to, say, API calls, so I really don't see any good reason to make an exception here.
What we should really remove is these calls (and not introduce new ones), not the comments reminding us to clean up the code by removing them - sooner (better) or later:
console.log("Invalid format on event api: ", message.data); |
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.
API calls that fail are prominently shown in the network tab in red. On failures, they are shown in the regular console.
Incoming messages on websockets are quite hidden under a WS tab in the Networks section and are prone to be overlooked. It is better to make the messages visible in the console if they are not handled than to drop them. The messages are not secret, because still discoverable with the debug interface of any decent browser - but a bit hard to find.
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.
Main point is: production code is not for debugging. You should not include any console.log
there. Which is why I introduced those TODO comments in the first place. If you want to keep the debugging code in production code: fine, I'm just pointing out (for the last time) that doing so is not a good practice, and they should be removed if we want to have a clean, production-ready code.
52aa45e
to
80b6829
Compare
80b6829
to
9f29825
Compare
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.
Just one small naming suggestion if you want, apart from that it's ready to go.
…ong running create process WD-4050
9f29825
to
a0e8e29
Compare
Done
Fixes WD-4050
QA