Don’t inspect API error messages to do template validation - #6040
Open
quis wants to merge 4 commits into
Open
Conversation
Catching an `HTTPError`` then Looking for a specific substring in something returned by the API is gross. Even morre so when it’s plonked in the middle of a view method. The pattern we follow elsewhere is generally: - validate in the admin app - pass to the API - validate on the API as a backup This is good because: - we have 2 lines of defence against bad data - the admin app code is simpler and easier to test - the admin app code follows the same pattern as other forms (using WTForms objects and methods) - the content error messages are codified in the admin app If the admin app lets something through which the API rejects then we get an exception, and we know we have something to investigate.
Catching an `HTTPError`` then Looking for a specific substring in something returned by the API is gross. Even morre so when it’s plonked in the middle of a view method. The pattern we follow elsewhere is generally: - validate in the admin app - pass to the API - validate on the API as a backup This is good because: - we have 2 lines of defence against bad data - the admin app code is simpler and easier to test - the admin app code follows the same pattern as other forms (using WTForms objects and methods) - the content error messages are codified in the admin app If the admin app lets something through which the API rejects then we get an exception, and we know we have something to investigate.
These are now redudant because all they are doing is re-raising the exceptions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Catching an
HTTPErrorthen looking for a specific substring in something returned by the API is gross. Even more so when it’s plonked in the middle of a view method (and the cyclomatic complexity check agrees 😈).The pattern we follow elsewhere, where possible, is:
This is good because:
If the admin app lets something through which the API rejects then we get an exception, and we know we have a mismatch to investigate. This is very unlikely since they are both using the same utils code to do the validation.