force-h2020 / force-bdss

Business Decision System general interface
BSD 2-Clause "Simplified" License
2 stars 2 forks source link

Different error messages reported for same Input/Output slot length verification #324

Closed flongford closed 4 years ago

flongford commented 4 years ago

As identified in #323, the length of input and output slot lists are being verified in two different places:

Original discussion:

This is in the master branch and is at least part of a error message raised by ExecutionLayer.execute_layer (line 101, execution_layer.py). I took it out and coverage works (locally) as well as codecov/patch. But codecov/project fails Whether it is there or not.

Ohhhh, I see what's going on now. Ok - this is worth a separate PR in its own right. It looks like there's two places where the input / output slot lengths are being checked - in the BaseDataSourceModel.verify method (which is called by verify_workflow) and also as you spotted in ExecutionLayer.execute_layer (which would have been reported back if we hadn't called verify_workflow first).

These means we would get 2 different error messages for the same error, depending on which method raised it - not ideal. We should make sure that this only happens in one place. I will make a new issue.

Originally posted by @flongford in https://github.com/force-h2020/force-bdss/pull/323

flongford commented 4 years ago

I think the error messages being reported in ExecutionLayer.execute_layer contain more useful information, but the BaseDataSourceModel.verify method should be the location where they are being raised (since we always verify the workflow first).

In which case, we could move these messages to become the local_error argument on the corresponding VerifierError instances in BaseDataSourceModel.verify (and then delete the code from ExecutionLayer.execute_layer that raises them).

These local_error attributes will then be added to the log in BaseOperation.verify_workflow.

sparsonslab commented 4 years ago

This is turning into another rabbit hole of unit test errors.