AlanCoding
commented
1 month ago Trying to give a skeptical self-review of this - the logic I'm building here starts to overlap significantly with get_or_create_resource, although that doesn't have the features I want to be thorough.
Outline of the abstract case
We are given an ansible_id and resource_data. We should also have a service_id, but we don't, that that's another novel issue.
We prioritize looking up the object by ansible_id, and we may or may not find it. If we find it, we're great! Move on. If we don't find it, then we want to create it. Creating the object may end in conflict, due to a pre-existing resource conflict. A conflict doesn't necessarily imply this type of conflict, because it could be due to another unknown database constraint implemented by the application. In this last case we should prefer to let it error and just log what happens, maybe catching any DatabaseError generally.
Problems with the existing method
The existing method would just error in the event of pre-existing resource conflicts. Should it?
There's no generalization of error handling in this respect, mainly because it doesn't do error handling. So we could tighten this code up in a couple of ways.
sonarcloud[bot]
Deep, deep, deep into a debugging hole, I thought I fixed the issue where the "admin" user had a resource conflict. But then it was still a conflict.
It was a conflict created by an entirely new mechanism. The JWT consumer was creating users from the JWT data that had a different ansible_id.
NOTE: We seem to have another problem where the
service_idis not set for absolutely anything created in this file.AAP-26659