-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add build and launch telemetry #594
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -100,6 +101,11 @@ export class DeviceSession implements Disposable { | |||
} | |||
|
|||
private async launchApp() { | |||
const launchReequestTime = Date.now(); |
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.
typo:
launchReequestTime -> launchRequestTime
waitForAppReady.then(() => clearTimeout(reportWaitingStuck)); | ||
} | ||
|
||
const [previewUrl] = await Promise.all([this.device.startPreview(), waitForAppReady]); |
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.
Shouldn't we wait for waitForAppReady once?
waitForAppReady.then(() => clearTimeout(reportWaitingStuck)); | |
} | |
const [previewUrl] = await Promise.all([this.device.startPreview(), waitForAppReady]); | |
} | |
const [previewUrl] = await Promise.all([this.device.startPreview(), waitForAppReady]); | |
if (shouldWaitForAppLaunch) { | |
clearTimeout(reportWaitingStuck); | |
} |
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 like my approach moare as it doesn't mix the reporting code with the existing logic. Whatever is placed inside that if block I added, is just for reporting and can be deleted. Otherwise I'd have to keep the reportWaitingStuck
in main scope, while we'd need to have shouldWaitForAppLaunch
checks both before and after the await.
On top of that this isn't really an equivalent, as the await is for both startPreview and app ready event.
const [previewUrl] = await Promise.all([this.device.startPreview(), waitForAppReady]); | ||
Logger.debug("App and preview ready, moving on..."); | ||
this.eventDelegate.onStateChange(StartupMessage.AttachingDebugger); | ||
await this.startDebugger(); | ||
|
||
const launchDurationSec = (Date.now() - launchReequestTime) / 1000; |
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.
typo:
launchReequestTime -> launchRequestTime
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.
Left some comments inline
This PR adds more loggind and telemetry around build and launch process.
Building and launching the app is one of the most fragile element of the IDE pipeline and we get numerous reports around that. While there are a few known issues around it that we are fixing and investigating. I figured it'd be good to also add telemetry around that such that we can track how it works for a larger group of people and also be able to detect regressions.
Test plan
Just run the example app with clean build and make sure nothing breaks.