Error Handling

Reminder

• use with transcation.atomic()
  • put multiple DB table changes in one with transcation.atomic()
  • put a single DB update/save with Curo call using submit_entity_unhandled
  • don’t use decorator @transaction.atomic to avoid future changes that introduces errors in error handling logics
• validate first, client facing logics last (e.g. sending emails)
• in Submission, avoid duplicate oneview and curo entities by using get_or_create?

Principles

• Error Handling means what are the correct business logics when errors happen
• consider curo as extension of oneview DB, so wrap curo call and DB changes in one transaction
• in general, one cannot revert a third party API call, because of possible side effects of the API call

Example: Curo

with transaction.atomic():
    task = Task.objects.create(...) # or update some properties then task.save()
    submit_entity_unhandled()

Example: Third Party API Call

# if response data is needed
foo_id = third party POST or PATCH
save `foo_id` to local DB

# if response data is not needed
with transaction.atomic():
    local db changes()
    third party POST or PATCH

• if third party call failed, not bad state, because there will be no local db changes.
• if save to local DB failed, bad state happened, maybe the solution is to verify first to avoid saving to local DB failed? because of the stable network or retry mechanism, unless this is DB constraint, save to local DB shouldn’t failed, so maybe verify can avoid the failure to local DB.

Regarding argument just put it in a queue and retry?

Answer:

• Putting some logics in a queue doesn’t solve the real problem of what should happen if this logics failed?
• and being async introduces complexity such as how to inform the user if this logics failed?
• when errors happen, which errors can be retried? which errors cannot be retried?