Why are we doing this?
We had a Sentry alert on Weds 29th July as a result of a number of requests to:
/codelist/{organisation_slug}/{codelist_slug}/{tag_or_hash}/dmd-download.csv
The dmd-download.csv view assumes it is being called for a BNF-based codelist. However, these requests were made for non-BNF codelists. For example:
When the view attempts to generate the download, it calls dmd_csv_data_for_download(), which asserts that the codelist is BNF-based. This raises an AssertionError, causing the request to return a 500.
From the investigation, it appears these requests were made directly to the endpoint (likely automated probing), rather than via the OpenCodelists UI. A full write-up of the investigation is available in the Slack thread here.
The endpoint currently returns a 500 for a request that cannot succeed. We should decide whether to:
- return a more appropriate response (for example,
404 not found), or
- leave the current behaviour unchanged.
We have had another Sentry alert today (Mon 3rd Aug) due to the above issue.
How will we know when it's done?
- We've decided whether to change the behaviour of this endpoint.
- If we're making a change, it has been implemented and deployed.
- If we're not making a change, we've documented the decision in this issue.
- The related Sentry issue has been
archived or resolved, as appropriate.
What are we doing?
Defining delivery tasks guidance
Why are we doing this?
We had a Sentry alert on Weds 29th July as a result of a number of requests to:
/codelist/{organisation_slug}/{codelist_slug}/{tag_or_hash}/dmd-download.csvThe dmd-download.csv view assumes it is being called for a BNF-based codelist. However, these requests were made for non-BNF codelists. For example:
When the view attempts to generate the download, it calls
dmd_csv_data_for_download(), which asserts that the codelist is BNF-based. This raises anAssertionError, causing the request to return a500.From the investigation, it appears these requests were made directly to the endpoint (likely automated probing), rather than via the OpenCodelists UI. A full write-up of the investigation is available in the Slack thread here.
The endpoint currently returns a
500for a request that cannot succeed. We should decide whether to:404not found), orWe have had another Sentry alert today (Mon 3rd Aug) due to the above issue.
How will we know when it's done?
archivedorresolved, as appropriate.What are we doing?
Defining delivery tasks guidance