-
Notifications
You must be signed in to change notification settings - Fork 598
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
Bigtable table.getRows() silently failing on queries > 4000 cells #1443
Comments
@imathews thanks for reporting this! I've managed to reproduce this locally, so definitely not an issue on your end. @murgatroid99 not sure if this is a implementation error on our side or not, but from what I can tell the |
Can you provide the output of running the client with the environment variable |
@murgatroid99 actually it appears to be an issue with one of our dependencies, I made a few local changes and grpc seems to be functioning as expected - my apologies for looping you in prematurely 😦 |
No problem. I'm glad to hear it's resolved. |
@murgatroid99 is there any specific reason why grpc does not emit a |
I'm not exactly sure which |
@murgatroid99 Gotcha, thanks! I apologize if my questions seem off, as I am not super familiar with the grpc code base. Essentially I'm looking for a way to confirm that the request went through successfully and that the server is going to process results, I think my issue was that I assumed the |
So, In general, I think receiving metadata is a good signal that the server has started to process the request. |
I'm fairly new to Bigtable, and my apologies if this is an issue on my end. I have a table where all rows have 84 cells; when I submit a getRows request with a limit >= 48 (total > 4000 cells) I get no error and no response. With a lower limit, everything works perfectly. Looking at my networking, it seems like there is data coming in, but otherwise I don't have much else to go off of.
This is happening both when I use the streaming and the callback APIs. Passing in a filter to reduce the number of returned columns doesn't change this behavior.
Many thanks for getting the Bigtable support out the door!
Environment details
OSX @10.11.4
node @6.2.0
npm @3.8.9
gcloud-node @0.37.0
Steps to reproduce
The text was updated successfully, but these errors were encountered: