Bug Description
When a comparison throws part way through, Schema Diff reports the failure and then immediately reports success as well, handing the client the objects it managed to get through as though the comparison were complete.
Both socket handlers in web/pgadmin/tools/schema_diff/__init__.py have the same shape:
except Exception as e:
app.logger.exception(e)
socketio.emit('compare_database_failed', str(e),
namespace=SOCKETIO_NAMESPACE, to=request.sid)
socketio.emit('compare_database_success', comparison_result,
namespace=SOCKETIO_NAMESPACE, to=request.sid)The except block does not return, so compare_database_success is emitted with whatever comparison_result had accumulated before the exception. compare_schema does the same with compare_schema_failed/compare_schema_success.
Whichever message the client acts on last wins, so a comparison that died after its first few node types can present as a short but perfectly ordinary result: objects that were never reached simply are not listed, and there is nothing in the result to say so. Anyone generating a script from that has a script covering part of the database.
Expected Behaviour
A failed comparison should report only the failure. The success message should be emitted only when the comparison actually completed.
Context
Found whilst making the Schema Diff regression test assert that applying the generated script leaves the two databases identical (#10293): a deliberately introduced error truncated the comparison from 151 objects to 42, and the test still saw a "successful" comparison of those 42. The test now also asserts that no failure message arrives.
Bug Description
When a comparison throws part way through, Schema Diff reports the failure and then immediately reports success as well, handing the client the objects it managed to get through as though the comparison were complete.
Both socket handlers in
web/pgadmin/tools/schema_diff/__init__.pyhave the same shape:The
exceptblock does not return, socompare_database_successis emitted with whatevercomparison_resulthad accumulated before the exception.compare_schemadoes the same withcompare_schema_failed/compare_schema_success.Whichever message the client acts on last wins, so a comparison that died after its first few node types can present as a short but perfectly ordinary result: objects that were never reached simply are not listed, and there is nothing in the result to say so. Anyone generating a script from that has a script covering part of the database.
Expected Behaviour
A failed comparison should report only the failure. The success message should be emitted only when the comparison actually completed.
Context
Found whilst making the Schema Diff regression test assert that applying the generated script leaves the two databases identical (#10293): a deliberately introduced error truncated the comparison from 151 objects to 42, and the test still saw a "successful" comparison of those 42. The test now also asserts that no failure message arrives.