Need to implement handling of failure scenarios for:

• MR interaction
  • >400 error, log(raise exception) and retry forever
  • if using a group of subscriptions or applying a sub to a group of NFs, retry mechanism should not block other subs/NFs
    • track state of NFs where sub was successfully applied, only retry on failed NFs
• A&AI interaction
  • if empty currently gives 404, log and raise exception, retry forever
• processing events
  • CREATE FAILED:
    • Trying to add a subscription to the NF and it fails to activate. 
    • creating a subscription with an invalid subscription object.
    • create fails when publishing message
    • retry on 500 error back from mr, log the error
    • 403 invalid user, log A&AI user in config is incorrect
  • DELETE FAILED:
    • Deleting a subscription of one or more NFs, but still keeping a subscription active on certain NFs 
    • Deleting a subscription when shutting down PMSH. How to handle failure to delete the subscription on some NFs? Retry and keep pmsh alive or just log the failures and shutdown anyway.
  • There may also be an issue that we never get a response from policy, thus leaving us in PENDING CREATE or PENDING DELETE, how long do we wait for the response to consider it a failure? And how do we handle this specific scenario? 
  • response event from policy
    • success/failed dependent on the event sent(CREATE/DELETE)
    • do we want state in event or state in application?
    • policy can fail due to unable to connect to CDS - retry
    • blueprint doesn't support object provided
• interaction with CBS
  • no improvements
• Database
  • no improvements

Also these failures can occur due to many issues along the line, sending the event, policy failing to send it to CDS and further on down the chain. There may be network issues or some components may be down and thus failing to proceed with the CREATE or DELETE. Should policy be sending back some error status and should we handle cases differently depending on that?