Call wake_up after the event has been already enqueued

[vimlucid]

• Closes connect_with_wakeup's wake_up is called before tx.send(event) #70

[c-git]

Thanks for pointing this out. Let's call wake_up on error as well. So let's move it after the if/else block and just store what we should return in a variable called something like result and then return it after calling wake_up.

I understand that they will no longer be able to receive the value sent on error but maybe they are not waiting on the value only the attempt to send in which case we would break their code thus making this a breaking change when there isn't a need for it to be.

[vimlucid]

Addressed.

As a side question since this is my first open source GitHub contribution - will you get a notification if I push commits into my own fork (if there's already a PR connected to the fork) or do I have to write a comment to notify you that I've addressed the comments. I'm asking in order to avoid creating unnecessary noise. At work we have separate channels to communicate "PR is ready for a second pass" - maybe it's a common rule that the PR owner should always write such a comment (because maintainers shouldn't look at multiple intermediate commits)?

One more side question 🙏 - the placeholder PR message said something like "PR should stay in draft mode until CI/CD checks have run" - however it seems CI/CD requires maintainer approval. After they approve the CI/CD run then at this point they've already seen the PR. What's the right thing to do here?

[c-git]

Addressed.

Thank you. Looks good.

As a side question since this is my first open source GitHub contribution ...

Very well done. I couldn't tell it was your first contribution.

... - will you get a notification if I push commits into my own fork (if there's already a PR connected to the fork) or do I have to write a comment to notify you that I've addressed the comments. I'm asking in order to avoid creating unnecessary noise. At work we have separate channels to communicate "PR is ready for a second pass" - maybe it's a common rule that the PR owner should always write such a comment (because maintainers shouldn't look at multiple intermediate commits)?

I did get a notification. But I'm not sure if that's a setting I put on or if it's the default. I don't think adding a comment would cause an issue but I don't know the general approach. I've always added a comment when I make changes when I'm the PR author but I don't know in general what is normally done. But for this crate, both are fine. I'll get the notification even if you don't put a comment.

One more side question 🙏 - the placeholder PR message said something like "PR should stay in draft mode until CI/CD checks have run" - however it seems CI/CD requires maintainer approval. After they approve the CI/CD run then at this point they've already seen the PR. What's the right thing to do here?

Thank you for that feedback. I will review the placeholder message in light of your comment and update it after I've given it some thought. It never crossed my mind to update it after I took over maintaining the crate.

[c-git]

The dependency issues are not related to this PR. I will update it after.