Thank you for the bug report @nuin. We've rewritten big parts of the web UI in 1.16, so this is probably a bug in the web UI that has slipped through the cracks.

Could you do two things for us to help us figure out what's going on?

• Check the development console if there are any JavaScript errors. In Firefox you can enable the "Web Console" in the Tools -> Web Developer sub menu. There will probably be a couple of CSS warnings already in there. The interesting ones are JS and Logging messages. In Chrome/Chromium I think JS errors show up on the "JavaScript console", which you can find in the Tools menu.
• Could you run r.db('genes').table('exons3').info() in the Data Explorer and report back the result?

Thank you for your help!

Hi @danielmewes
There are 3 errors being reported, 2 on the Tables page and another on the table-specific page pointing to same source link:

[Error] Failed to load resource: the server responded with a status of 400 (Bad Request) (reql, line 0) 
on different conn_id:
http://192.168.1.83:8080/ajax/reql/?conn_id=197
http://192.168.1.83:8080/ajax/reql/?conn_id=200
http://192.168.1.83:8080/ajax/reql/?conn_id=204

And the .info on the table

{
"db": {
"id":  "21cc26df-6bf2-4e25-94d3-eb9100ba29d9" ,
"name":  "genes" ,
"type":  "DB"
} ,
"doc_count_estimates": [
74744
] ,
"id":  "ca6071fc-a806-493d-9c98-7f13c341e11a" ,
"indexes": [ ],
"name":  "exons3" ,
"primary_key":  "id" ,
"type":  "TABLE"
}

Thanks

Thanks for the info @nuin . We'll investigate. Does the problem persist if you reload the page?

In case we cannot reproduce it ourselves, is there a chance you could give us your RethinkDB data folder? We would be happy to sign an NDA if it contains any sensitive information.

Hi @danielmewes

Nothing changes with a reload.

I guess I can send the data if needed. Just need to check if there's anything sensitive, but from the top of my head I don't think there is.

One question @danielmewes: my machines are behind a firewall and some ports (outbound) are closed, would that be an issue for those connections? As far I can see in the errors it's trying to connect to my intranet IP, just wondering if something goes outbound in a different port.

@nuin It should be using the same port (8080) for all of its requests (and the same local server), so if there was a problem with that I would expect the web UI to not work at all. Theoretically there's a chance that something is special with this specific request (e.g. it takes longer than the others or something like that) which causes it to be interrupted by the firewall, but I don't think that's very likely.

@nuin are you using Safari?
I just saw the same error appear in the log with Safari, though on the dashboard rather than a table page.
Do you have any other browser installed that you could try?

@danielmewes I just ran into this in Chrome 40. I was on the table overview page and when I tried to navigate to the Data Explorer from the menu bar everything blanked out like in @nuin's first screenshot. I can't seem to reproduce it again but I'll keep an eye out.

@danielmewes Yes, running mostly on Safari. I will try Firefox and Chrome and report.

Thanks

@danielmewes All good on Chrome checking the two boxes. Notice that I am on the VPN now, and both Chrome and Safari work fine. I will test again tomorrow on my work box using Chrome and Firefox.

Ok I found the reason for why this is happening.
In the web UI we're emulating ReQL connections over HTTP. To open such a "virtual" connection, we send a request to the server first. The server then assigns a connection ID to the virtual connection and sends that back to us. For all future requests on this virtual connection we submit the connection ID so the server can associate the request with the right virtual connection.

What's happening now is that sometimes the browser caches the initial request, so the "establish connection" request never goes to the server. Instead multiple virtual connections will use the same connection ID, with all sorts of bad consequences.

@danielmewes Do you still need my data dir? No problem uploading it tomorrow.

Fix in CR 2569.

@nuin I think we found the problem, so we won't need your data. Thank you though for offering to upload it!

I will close the ticket then, thanks a lot.

Re-opening until the change is merged. It's currently in code-review. (that's just our convention on how we use the issue tracker).
If everything goes well, we are going to ship the fix with a 1.16.1 point release pretty soon.

@danielmewes OK, thanks.

Closed in v1.16.x 51edc38 and next 437a362

Going to ship in 1.16.1.

@nuin this should be fixed in RethinkDB 1.16.1, which is now available. Please let us know if you notice anything else.