skip erroring ooi's in ooi_repository.py

[underdarknl]

Add code to not crash the entire result set when objects could not be shoehorned into our current ooi models.

Changes

This Pr add's some code to optionally send an error instead of crash on database content that does not fit the current OOI models. These crashes have a ripple effect where services don't get any data (eg, rocky), or crash themselves.
Erroring ooi's will be skipped, and an error is logged in Octopoes_api.

Issue link

You have to create an issue to link to this PR. If this really is not possible, write a very detailed description here and add this PR to the project board directly.

Please add the link to the issue after "Closes".

Closes ...

Demo

QA notes

Please add some information for QA on how to test the newly created code.

---

Code Checklist

• All the commits in this PR are properly PGP-signed and verified.
• This PR only contains functionality relevant to the issue.
• I have written unit tests for the changes or fixes I made.
• I have checked the documentation and made changes where necessary.
• I have performed a self-review of my code and refactored it to the best of my abilities.

• Tickets have been created for newly discovered issues.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have included comments in the code to elaborate on what is not self-evident from the code itself, including references to issues and discussions online, or implicit behavior of an interface.

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

[underdarknl]

As discussed, Ill add an OOI like object to carry the errors (and the why) from the backend into the frontend.

[ammar92]

I think the suggested OOI is not ideal since it isn't really an OOI. An alternative approach could be to allow this class but not treat it as an OOI type. However, this would require some type refactoring and frontend work to handle this record differently.

That said, this is a good step toward addressing the problem. We have mismatches between the database and models and it's important to be able to highlight these instances

[underdarknl]

I think the suggested OOI is not ideal since it isn't really an OOI. An alternative approach could be to allow this class but not treat it as an OOI type. However, this would require some type refactoring and frontend work to handle this record differently.

That said, this is a good step toward addressing the problem. We have mismatches between the database and models and it's important to be able to highlight these instances

I agree in principal. However, we do expect OOI like objects in all the consumers of these lists. We could (like I started doing) add the non OOI subclassed parse/validation error object to the expected list of types, and handle it everywhere, of we could 'pretend for the error to be OOI like'

[sonarqubecloud]

Quality Gate failed

Failed conditions
56.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud