Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial exception handling enhancements #77

Merged
merged 2 commits into from
May 10, 2023
Merged

Conversation

rtamalin
Copy link
Contributor

@rtamalin rtamalin commented May 9, 2023

Enhance the exception handling support for code paths related to the the initial start up of the CSP Billing Adapter.

  • failures retrieving existing data from data stores that may not exist yet are handled gracefully, without the main event loop seeing them.

  • failures creating/initializing key data stores are reported and an exception is raised that will cause the main event loop to fail.

  • failures to retrieve usage data, which may not have been published yet, are handled gracefully, skipping follow on metering attempt for now, and without the main event loop seeing them. NOTE: If this issue persists this would lead to metering not being performed, but performing metering would overwrite the error that was reported for the get_usage_data() operation.

Add tests to exercise and validate the new exception handling code.

Remove stale code from test_event_loop_handler() relating to log var.

Re-word the cba_pm docstring message to better reflect what it does.

Implements: #70

Enhance the exception handling support for code paths related to the
the initial start up of the CSP Billing Adapter.

  * failures retrieving existing data from data stores that may not
    exist yet are handled gracefully, without the main event loop
    seeing them.

  * failures creating/initializing key data stores are reported and
    an exception is raised that will cause the main event loop to
    fail.

  * failures to retrieve usage data, which may not have been published
    yet, are handled gracefully, skipping follow on metering attempt
    for now, and without the main event loop seeing them.
    NOTE: If this issue persists this would lead to metering not being
    performed, but performing metering would overwrite the error that
    was reported for the get_usage_data() operation.

Add tests to exercise and validate the new exception handling code.

Remove stale code from test_event_loop_handler() relating to log var.

Re-word the cba_pm docstring message to better reflect what it does.

Implements: #70
'timestamp': date_to_string(now),
'billing_api_access_ok': False,
'errors': [
f'Usage data retrieval failed: {exc}'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be helpful to track state during each cycle and any error messages and update it at the end of the loop. This way the state of the adapter is updated separately of the actions and state independent data.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, but for such a case we may want to clarify how that is reflected in the csp_config data, as per my comments in #70.

# worth considering.
# However, doing so will currently result in the error state
# that was saved in the csp_config being lost, as it would be
# overwritten with a success state, or a different error.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A number of calls inside else clause could also fall over. It might make for cleaner exception handling if any early exit of event loop is handled with a "continue". Also the rest of the loop is not necessarily tied to one function. In this case if the adapter cannot get usage data it probably shouldn't prevent the adapter from billing if it's time to bill and there's something in cache to bill. To avoid loss of state it could be tracked and only updated once at the end of loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed that the else clause had more candidates for exception handling improvements.

However, some refactoring will be needed to support that effort, per my comments in #70, so it may be worth doing this work in incremental steps, organically growing towards the desired end goal of more complete exception handling.

@rtamalin
Copy link
Contributor Author

@smarlowucf given that this PR, while not completely addressing all of the relevant exception handling scenarios, is focused on addressing a number of such cases that occur during the initial deployment startup, I'd prefer to get these changes landed, and work on further exception handling enhancements in follow-on PRs.

@rtamalin
Copy link
Contributor Author

Github actions is having issues running the checks right now; happy to merge as is if you are ;-)

@smarlowucf
Copy link
Collaborator

Fine by me. It looked like the runs the worked passed. 👍

@rtamalin rtamalin merged commit d21de17 into main May 10, 2023
@rtamalin rtamalin deleted the exception_handling branch May 10, 2023 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants