Fix for create_network in interface API, properly deserializing AlchemicalNetwork #276
Conversation
…micalNetwork Previously, we were relying on `fastapi` to decode the JSON form of the request, which was not using `gufe.tokenization.JSON_HANDLER.decoder`. This resulted in `Settings` objects not being turned into `pydantic` models from `dict` form, which silently worked until now before changes in `gufe` for 1.0, in which `Protocol` now requires `settings` to be an actual `Settings` object on init.
Since the "incomplete" network's edges are a subset of the full network, we need to select transformations from the "incomplete" network. Without this, there is a small chance that a Transformation is not part of the incomplete network, which, in our tests we always assume the attached TaskHub has three available tasks available to claim. Additionally, I've added a couple more assertions checking these assumptions.
|
@dotsdl There was a bug in the preloaded database fixture. At first it appeared random (like the supposed race conditions we have seen before). Upon further inspection I couldn't figure out how it could have been. Rerunning the tests many times locally, I finally caught one in the debugger. Long story short, we were trying to actions tasks for transformations that were not part of the alchemical network and our failing test relied on all tasks being actioned to pass.
|
ianmkenney
changed the title
Great detective work on this @ianmkenney! Thanks for fixing this bug in the test suite! |
Directly handle the request to
create_networkusing the gufeJSON_HANDLERto properly decode the containedSettingsobjects.Since these changes also work with
gufe < 1.x.x, this PR shouldn't be blocked by #254.