-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add Additional Logging for new endpoint #3779
Add Additional Logging for new endpoint #3779
Conversation
JaCoCo Test Coverage
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work here! Just one comment - Could the new code in log_contention_stats
be broken into its own helper function?
if request.url.path == "/expanded-contention-classification": | ||
processed_text = expanded_lookup_table.prep_incoming_text( | ||
contention.contention_text | ||
) | ||
# only log these items if the expanded lookup returns a classification code | ||
if expanded_lookup_table.get(contention.contention_text)["classification_code"]: | ||
if log_contention_text == "unmapped contention text": | ||
log_contention_text = f"unmapped contention text {[processed_text]}" | ||
|
||
logging_dict.update( | ||
{ | ||
"processed_contention_text": processed_text, | ||
"contention_text": log_contention_text, | ||
} | ||
) | ||
# log none as the processed text if it is not in the LUT and leave unmapped contention text as is | ||
else: | ||
logging_dict.update({"processed_contention_text": None}) | ||
log_as_json(logging_dict) | ||
else: | ||
log_as_json(logging_dict) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if broke this code out into a helper function? Something like:
def _update_logging_for_expanded_contention(
logging_dict: dict, contention_text: str, log_contention_text: str
):
"""
# Updates the logging dictionary for `/expanded-contention-classification`
"""
processed_text = expanded_lookup_table.prep_incoming_text(contention_text)
classification = expanded_lookup_table.get(contention_text)
if classification.get("classification_code"):
if log_contention_text == "unmapped contention text":
log_contention_text = f"unmapped contention text {[processed_text]}"
logging_dict.update(
{
"processed_contention_text": processed_text,
"contention_text": log_contention_text,
}
)
# log none as the processed text if it is not in the LUT and leave unmapped contention text as is
else:
logging_dict.update({"processed_contention_text": None})
return logging_dict
That is then used like:
if request.url.path == "/expanded-contention-classification":
logging_dict = _update_logging_for_expanded_contention(
logging_dict, contention_text, log_contention_text
)
log_as_json(logging_dict)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for checking out the comment! Glad it looked like a positive change. This PR looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
) | ||
|
||
# log_as_json(logging_dict) | ||
# else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this commented-out code left in deliberately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gabezurita Sorry I missed this comment before merging. That was accidentally left behind, I will clean this up in a following PR.
What was the problem?
This adds a new field to logging and updates an existing field for only the new expanded classifier.
Previous Logging:
New Logging for expanded classifier:
The additional field of
processed_classified_text
will us compare classifications based on the text processing lookup. This should also prevent logging any PII because we will only log the contention text if there is a match with the lookup table after processing. Additionally adding the processed text in the contention text field will help with our DataDog widgets to differentiate between unclassifiable unmapped text and classifiable unmapped text.Associated tickets or Slack threads:
How does this fix it?1
How to test this PR
Footnotes
Pull-Requests guidelines. If PR is significant, update Current Software State wiki page. ↩
To check if a PR will succeed in the SecRel workflow, test PRs in the SecRel pipeline. ↩