Issue 1:
Hi everybody,

We use Superset (incubator) since a few weeks now, and we use it to execute queries on PrestoDB cluster.

But we encounter a problem while running a basic SELECT query which is lasting about 4 to 5 minutes (so a long one).

The query is run asynchronously but the same error appears while running the same query synchronously.

Superset version

0.28.1

Expected results

The query runs until success and the result is displayed in the SQL Lab interface.

Actual results

The HTTP request to the /sql_json API is failing with the 500 status code, around 3 to 4 minutes after the query is executed.

However, the query executed in PrestoDB cluster is completed after 4 to 5 minutes. That is to say the problem is not on the PrestoDB cluster side.

The stack trace resulting is the following :

Traceback (most recent call last):
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py&#34;, line 1193, in _execute_context
context)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/default.py&#34;, line 507, in do_execute
cursor.execute(statement, parameters)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 226, in execute
self.errorhandler(self, exc, value)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/connections.py&#34;, line 36, in defaulterrorhandler
raise errorvalue
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 217, in execute
res = self._query(query)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 378, in _query
rowcount = self._do_query(q)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 341, in _do_query
db.query(q)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/connections.py&#34;, line 280, in query
_mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, &#34;Duplicate entry &#39;2AhlO0vMH&#39; for key &#39;client_id&#39;&#34;)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File &#34;/usr/local/lib/python3.6/site-packages/flask/app.py&#34;, line 1982, in wsgi_app
response = self.full_dispatch_request()
File &#34;/usr/local/lib/python3.6/site-packages/flask/app.py&#34;, line 1614, in full_dispatch_request
rv = self.handle_user_exception(e)
File &#34;/usr/local/lib/python3.6/site-packages/flask/app.py&#34;, line 1517, in handle_user_exception
reraise(exc_type, exc_value, tb)
File &#34;/usr/local/lib/python3.6/site-packages/flask/_compat.py&#34;, line 33, in reraise
raise value
File &#34;/usr/local/lib/python3.6/site-packages/flask/app.py&#34;, line 1612, in full_dispatch_request
rv = self.dispatch_request()
File &#34;/usr/local/lib/python3.6/site-packages/flask/app.py&#34;, line 1598, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File &#34;/usr/local/lib/python3.6/site-packages/flask_appbuilder/security/decorators.py&#34;, line 52, in wraps
return f(self, *args, **kwargs)
File &#34;/usr/local/lib/python3.6/site-packages/superset/models/core.py&#34;, line 1017, in wrapper
value = f(*args, **kwargs)
File &#34;/usr/local/lib/python3.6/site-packages/superset/views/core.py&#34;, line 2509, in sql_json
session.flush()
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/session.py&#34;, line 2243, in flush
self._flush(objects)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/session.py&#34;, line 2369, in _flush
transaction.rollback(_capture_exception=True)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/util/langhelpers.py&#34;, line 66, in __exit__
compat.reraise(exc_type, exc_value, exc_tb)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/util/compat.py&#34;, line 187, in reraise
raise value
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/session.py&#34;, line 2333, in _flush
flush_context.execute()
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/unitofwork.py&#34;, line 391, in execute
rec.execute(self)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/unitofwork.py&#34;, line 556, in execute
uow
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/persistence.py&#34;, line 181, in save_obj
mapper, table, insert)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/persistence.py&#34;, line 866, in _emit_insert_statements
execute(statement, params)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py&#34;, line 948, in execute
return meth(self, multiparams, params)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/sql/elements.py&#34;, line 269, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py&#34;, line 1060, in _execute_clauseelement
compiled_sql, distilled_params
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py&#34;, line 1200, in _execute_context
context)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py&#34;, line 1413, in _handle_dbapi_exception
exc_info
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/util/compat.py&#34;, line 203, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/util/compat.py&#34;, line 186, in reraise
raise value.with_traceback(tb)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py&#34;, line 1193, in _execute_context
context)
File &#34;/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/default.py&#34;, line 507, in do_execute
cursor.execute(statement, parameters)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 226, in execute
self.errorhandler(self, exc, value)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/connections.py&#34;, line 36, in defaulterrorhandler
raise errorvalue
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 217, in execute
res = self._query(query)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 378, in _query
rowcount = self._do_query(q)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/cursors.py&#34;, line 341, in _do_query
db.query(q)
File &#34;/usr/local/lib/python3.6/site-packages/MySQLdb/connections.py&#34;, line 280, in query
_mysql.connection.query(self, query)
sqlalchemy.exc.IntegrityError: (_mysql_exceptions.IntegrityError) (1062, &#34;Duplicate entry &#39;2AhlO0vMH&#39; for key &#39;client_id&#39;&#34;) [SQL: &#39;INSERT INTO query (client_id, database_id, tmp_table_name, user_id, status, tab_name, sql_editor_id, `schema`, `sql`, select_sql, executed_sql, `limit`, limit_used, select_as_cta, select_as_cta_used, progress, `rows`, error_message, results_key, start_time, start_running_time, end_time, end_result_backend_time, tracking_url, changed_on) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)&#39;] [parameters: (&#39;2AhlO0vMH&#39;, 2, &#39;&#39;, &#39;2&#39;, &#39;running&#39;, &#39;Untitled Query&#39;, &#39;kvGcgs0TC&#39;, None, &#34;SELECT XXX&#39;&#34;, None, None, None, 0, 0, 0, 0, None, None, None, 1553848436421.259, None, None, None, None, datetime.datetime(2019, 3, 29, 8, 33, 56, 423599))] (Background on this error at: http://sqlalche.me/e/gkpj)

Steps to reproduce

Run a long execution time query (around than 4 to 5 minutes), and wait until the HTTP request fails.

Issue 2:
This is a proposal to edit the frontend testing guidelines from:

Avoid nesting when you're testing
Avoid the use of describe blocks in favor of inlined tests. If your tests start to grow and you feel the need to group tests, prefer to break them into multiple test files. Check this [awesome article](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing) written by Kent C. Dodds about this topic.

to

Avoid unnecessary abstractions
Even though there may be a lot of duplication in tests because you are performing the same actions many times, avoid too many abstractions and drying up code if it means that the tests become unreadable. If almost each line in your test is calling a function defined in a beforeEach block for example, consider its readability and bringing that code back into the test, especially if it's a short block of code that is repeated. There are some good examples of this readability issue in [this article here](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing).

I feel that the sentiment of KCD's article is to avoid too much abstraction that would make tests difficult to read. There are still benefits to nesting in describe for the purpose of keeping scenarios together, especially since jest strings together describe tags. i.e.,

describe('myComponent', () => {
describe('when user is logged in', () => {
describe('and they do not have a photo', () => {
it('should do something')
});
describe('and they do have a photo', () => {
it('should do something')
});
});
describe('when the user is not logged in', () => {
it('should do something')
});
});

This writes out the test case like: 'myComponent when user is logged in and they do not have a photo'

so it's very convenient to make sure that you're covering a binary set of cases and still have a readable output.