-
Notifications
You must be signed in to change notification settings - Fork 5
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
Heimdall prompts users of the zoom command to post meeting notes after the meeting #56
Conversation
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.
starting a review bc I'm leaving some comments/ questions in the diff, and.. yeah.
52746ce
to
4a374ef
Compare
bc64c1c
to
b2d2d3f
Compare
If meeting never starts after specified delay, we stop watching If meeting starts and ends, we prompt the user to post notes in flow If meeting starts, but does not end within specified delay, we assume it still happened, and send a prompt anyway If there are errors at any point in this process, we log them, and in some cases send user a message about the error
1f16210
to
5d766f1
Compare
If meeting never starts, send prompt to start another if needed If meeting starts and ends within timeout, send prompt to user to post meeting notes If meeting starts but does not end within timeout, we assume it still happened and send the prompt to post notes, but do not mention user
Update constants values to reasonable defaults Remove debug logging
I do believe this puppy is ready for review, @Shadowfiend |
Oh snizzle snaps. |
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 thoughts. The naming stuff and nested if
stuff I think is best addressed here, while the return value structure, a potential revision to use async
/await
, and pulling this functionality into Session
, I think is best left for a follow-up refactoring PR.
@@ -144,4 +157,4 @@ class Account { | |||
} | |||
} | |||
|
|||
export { getSession, Session } | |||
export { getSession, Session, getMeetingDetails } |
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.
Let's make a note to refactor this one and pull it into Session
. I think that + refactoring to async/await below can be one bundle.
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.
created issue #62 for the refactoring follow-up
scripts/zoom.js
Outdated
}) | ||
.catch(err => { | ||
robot.logger.error( | ||
"Failed to fetch next available meeting:", | ||
util.inspect(err), | ||
) | ||
res.send("Uh-oh, there was an issue finding an available meeting :(") | ||
return |
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.
You don't need this return
, as it's basically the same as letting the function end.
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.
ah good to know. at some point in my testing I was hitting a .then()
block when I didn't expect to, but I think I over-corrected and just put returns everywhere :)
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.
yeahhhh nope. flat-out over-compensating. cleaned em up.
scripts/zoom.js
Outdated
} | ||
|
||
function watchMeeting(meeting) { | ||
let startIntervalIdPromise = new Promise((resolve, reject) => { |
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 would rename this meetingStartedPromise
. When this promise resolves, it indicates whether the meeting started (true
) or not ("never started"
, which incidentally should probably just be false
).
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.
good call. I thought there was a reason I did this.. but the reason may very well have been based on a misunderstanding. I'll clean this up (and report back here if I end up running into the thing I was trying to avoid)
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.
yeahhhh nope. flat-out over-compensating. cleaned em up. (wrong thread)
scripts/zoom.js
Outdated
}, MEETING_START_TIMEOUT_DELAY) | ||
}) | ||
return startIntervalIdPromise.then(meetingStartStatus => { | ||
let endIntervalIdPromise = new Promise((resolve, reject) => { |
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.
Similarly, this can be meetingEndedPromise
.
We'll also want to consider how this promise resolves. Right now it can resolve with one of three values:
"never started"
true
null
I think we'll want to align these into one type, which could be a set of constant strings:
"never started"
"finished"
"timed out"
We can do this in a refactoring follow-up.
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.
created issue #62 for the refactoring follow-up
}) | ||
.then(meeting => { | ||
robot.logger.info(`Start watching meeting: ${meeting.id}`) | ||
return watchMeeting(meeting) |
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.
watchMeeting
could fluently be named waitForMeetingEnd
, which would make this read waitForMeetingEnd(...).then(do stuff)
.
scripts/zoom.js
Outdated
.then(meeting => { | ||
robot.logger.info(`Start watching meeting: ${meeting.id}`) | ||
return watchMeeting(meeting) | ||
.then(fulfilledPromise => { |
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.
At this point this is no longer a promise, it's now the final value that the endIntervalIdPromise
/meetingEndedPromise
resolves. So this is really just meetingEndStatus
or something of the sort.
scripts/zoom.js
Outdated
robot.logger.info(`Start watching meeting: ${meeting.id}`) | ||
return watchMeeting(meeting) | ||
.then(fulfilledPromise => { | ||
if (fulfilledPromise) { |
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.
Rather than nesting ifs here, I think you can compare fulfilledPromise
to the three possibilities from my comment above in a single if/else if/etc.
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.
Clarifying question re your comment above:
The naming stuff and nested if stuff I think is best addressed here, while the return value structure [...] I think is best left for a follow-up refactoring PR
Is there a way to clean up the nested if now, w/o addressing the return value structure at the same time? (I'm interpreting them as related)
If not, would you prefer that I punt both to v2 or address both here?
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.
oh.
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.
addressed in 27392cb944bc4
scripts/zoom.js
Outdated
robot.logger.info( | ||
`Stopped watching, meeting still going: ${meeting.id}`, | ||
) | ||
return |
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.
Similarly, you don't need any of these returns as they are all at the end of their respective branches in the function.
scripts/zoom.js
Outdated
util.inspect(err), | ||
) | ||
// We assume the meeting still happened, so reply (but without `@`) | ||
res.send(`Don't forget to post meeting notes when your call ends!`) |
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 would include “Something went wrong watching the meeting; don't forget...” Otherwise there's an unexplained difference in behavior for the users!
@Shadowfiend I think I hit all the for-this-iteration notes, and moved the for-next-iteration notes into a new issue. Ready for re-review when you have a chance - let me know if you spot anything I missed! |
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.
Okay this looks good… Will wait to merge until we chat about announcing the change.
Closes #46
To encourage folks to externalize conversations that happen in zoom chats, Heimdall will keep an eye on meetings initiated by the zoom command, and send a note to the remind the people using that zoom to follow up by posting meeting notes.
TODO:
some othese commits?)