-
Notifications
You must be signed in to change notification settings - Fork 235
fix(close): ensure in-flight messages are drained #952
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
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
|
@googlebot I signed it! |
|
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
|
Thanks for the contribution, @jeffijoe ! I'll review in just a sec. |
test/message-queues.ts
Outdated
| const origSendBatch = patchedQueue._sendBatch; | ||
| const log: string[] = []; | ||
| const sendDone = defer(); | ||
| patchedQueue._sendBatch = async function _sendBatch( |
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 wonder if this might be done using sandbox.stub just to be consistent with the rest of the tests. I'm going to ask someone who knows a bit more about Sinon than me.
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.
Do you mean just the patching of the method?
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.
Yep! Sorry for not being clear there. On second thought, I think it's not a big deal because you're making your own MessageQueue anyway.
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 wanted to stay consistent with the rest of the source but I was not sure how else I would pull this off. Do you have any suggestions?
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 think you could probably use the sandbox on the existing messageQueue._sendBatch, if you wanted to be a bit more consistent with the other tests. That might be nice if we change something about how the "global" MessageQueue is wired up under describe later, but I don't think it's worth spending much time on.
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 changed it and rebased to tip of master but now other unrelated tests are failing. Is master healthy right 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.
It should be, but we have been tracking down some flaky tests for a bit, too. I'll look.
|
If you are wondering about the force-pushes, I am just rebasing to latest |
|
Yep, no worries on the rebase! |
|
I think the rebase is actually confusing our CI bots, so you might want to just use merge to get the tests running automatically. |
|
Kokoro seemed to have issues even with my first non-rebased commit though? I can push a dummy commit if you want and see if it resolves anything? |
|
Sure, let's try it for science :) It looks like the checks are passing at this point. Hopefully we'll have our automated sample failure bot going on this repo soon. |
src/message-queues.ts
Outdated
| deferred.resolve(); | ||
| } | ||
|
|
||
| if (this.numInFlightRequests === 0 && this._onDrain) { |
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, super minor thing here that I thought @bcoe was going to comment on - to be overly defensive, it might be nice to make this <= 0.
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.
Done! :)
|
Apparently the actual issue with the CI here is that Kokoro is having issues. I'll try to get this merged tomorrow. |
Track in-flight requests and add an `onDrain`deferred that resolves when all in-flight requests are done.
Track in-flight requests and add an `onDrain`deferred that resolves when all in-flight requests are done. Co-authored-by: Megan Potter <57276408+feywind@users.noreply.github.com> Co-authored-by: Benjamin E. Coe <bencoe@google.com>
* fix(close): ensure in-flight messages are drained (#952) Track in-flight requests and add an `onDrain`deferred that resolves when all in-flight requests are done. Co-authored-by: Megan Potter <57276408+feywind@users.noreply.github.com> Co-authored-by: Benjamin E. Coe <bencoe@google.com> * chore: update equal to strictEqual for linter changes Co-authored-by: Jeff Hansen <jeffijoe@hotmail.com> Co-authored-by: Benjamin E. Coe <bencoe@google.com>
…is#952) The Bigtable data protocol is substantially different from it's api and cannot be expressed using GAPIC generator alone. Instead a manually written layer was created to sit on top of the raw gapic & protobuf apis. Thus our public surface is the manual layer, while the autogenerated code is considered an internal implementation detail. To avoid confusing users, we should stop publishing docs for internal apis. Co-authored-by: kolea2 <45548808+kolea2@users.noreply.github.com>
Track in-flight requests and add an
onDraindeferred that resolves when all in-flightack/modAcksare done.Fixes #951