Unable to query the Thimble database from our sweet dashboard.

[flukeout]

The dashboard lives on: https://thimble-dashboard-staging.herokuapp.com/

Some queries seem to work, though. Check out below

• The graph is blank, it tries to query the projects table
• The thumbnails are populated, they are obtained by querying the publishedProjects table

Are there different permissions set on this?

I'm also unable to connect to the database at all from my desktop database app.

@jbuck Are there some new security rules that are preventing my app from working?

cc @humphd @sedge

[humphd]

This is what I reported in the Thimble bug, and it's just 503'ing:

curl -I https://thimble-dashboard-staging.herokuapp.com/count-created\?date\=2015+11+05
HTTP/1.1 503 Service Unavailable
Connection: keep-alive
Server: Cowboy
Date: Sat, 07 Nov 2015 18:07:00 GMT
Content-Length: 484
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache, no-store

[sedge]

The attempt to connect to postgres fails with an ETIMEDOUT error. A ping to the database confirms the service is active, as does the fact that Thimble still runs.

@jbuck Are we hitting a limit on the number of clients that can connect at once? I wonder how often clients are released back into the pool.

[sedge]

The dashboard creates a new client connection for every request. That might cause issues if there's a limited number of clients connections available.

[flukeout]

Actually, it looks like some of the queries I was using are no longer working, so there may be something else at play...

[humphd]

@flukeout there was work to convert date types, which might be what this is? cc @gideonthomas

[flukeout]

@Pomax @gideonthomas It looks like some Thimble projects have made it into the projects table, and they have a different date format for date_create and date_updated than existing Thimble projects. This is causing my queries to break and the dashboard to not work.

What's the plan on this? Will they be the same ultimately? Should I account for this somehow in my dashboard code?

cc @chadsansing

[gideonthomas]

@flukeout I'm working on a patch that will store them as datetime sql types so that should fix this. I'm not sure what caused it to have epoch-based time though (seems like they all have "X-Ray Goggles" in their name so maybe that has something to do with it :P)

[Pomax]

https://github.com/mozilla/goggles.webmaker.org/blob/master/views/publication.js#L278-L286 looks like the culprit. Another reason why publish.wmo, not clients, should control creation and update dates =)

[jbuck]

Okay, so it sounds like this is just a "unexpected data in the database" issue causing the query to not work, right? As opposed to not having access or something like that

[jbuck]

I think @gideonthomas will fix this when he lands his date handling patch. In the meantime, you could patch goggles to send date strings instead of unix timestamps, and use sql to convert the existing timestamps to iso strings.

[Pomax]

filed mozilla/goggles.mozilla.org#257 to track that over on the goggles repo