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

Adding more detailed debugging output #342

Closed
wants to merge 1 commit into from

Conversation

skyemeedan
Copy link
Contributor

adding more detailed error debugging output in the response when alegre is unable to find the requested model on lookup (perhaps because skye forgot to start it in the local dev ..)

Note: my editor is applying an opinionated formatter, which has adjusted whitespace to python standards. The actual change is on line 64, adding:

 assert model_info is not None, f"Unable locate model info for key {model_key}"

Description

Please include a very brief high-level description of the problem or feature and technical details or specific code changes on PR

Reference: TICKET-ID (to provide additional context)

How has this been tested?

Has it been tested locally?
I confirmed that the alegre system ran locally and gave the desired error response

Are there automated tests?
none added

Have you considered secure coding practices when writing this code?

This does return additional detail on an error, which can leak info about internal state of the system, however this is an internal service API

is unable to find the requested model on lookup
(perhpas because it i has not started)
@codeclimate
Copy link

codeclimate bot commented Sep 18, 2023

Code Climate has analyzed commit d226820 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 86.8% (50% is the threshold).

This pull request will bring the total coverage in the repository to 88.2% (0.0% change).

View more on Code Climate.

Copy link
Contributor

@DGaffney DGaffney left a comment

Choose a reason for hiding this comment

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

I know I'm making some comments about code that pre-existed you jumping in here but may be worth addressing some of them while you're here?

self.respond(task.task_package)
@staticmethod
def import_model_class(model_class):
class_name = re.sub(r"(?<!^)(?=[A-Z])", "_", model_class).lower()
Copy link
Contributor

Choose a reason for hiding this comment

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

What would be the source of a model class name where it could even potentially fall afoul of this list? Is it free text entry at some point upstream of here?


@staticmethod
def get_client(model_key, options={}):
r = redis.Redis(
Copy link
Contributor

Choose a reason for hiding this comment

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

You're instantiating like this over and over. Maybe worth having a RedisServer module or something?

def __init__(self, model_key, options={}):
self.options = options
self.queue_name = model_key
self.datastore = redis.Redis(
Copy link
Contributor

Choose a reason for hiding this comment

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

Again, there's a ton of redis.Redis in this file - feels like this could be DRY'ed up a bit

def get_task(self, timeout=0):
item = self.datastore.blpop(self.queue_name, timeout)
if item:
task = Task(**json.loads(item[1].decode("utf-8")))
Copy link
Contributor

Choose a reason for hiding this comment

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

Worth using pydantic validation on the task data maybe?

@skyemeedan
Copy link
Contributor Author

This PR is intended a one line change to give more descriptive errors back to the caller that I needed timpani debugging. I could open a ticket for more general cleanup of shared_model code and move these comments there?

@DGaffney
Copy link
Contributor

DGaffney commented Oct 3, 2023

This PR is intended a one line change to give more descriptive errors back to the caller that I needed timpani debugging. I could open a ticket for more general cleanup of shared_model code and move these comments there?

Seems reasonable - @computermacgyver what do you think?

Copy link
Contributor

@computermacgyver computermacgyver left a comment

Choose a reason for hiding this comment

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

Agree. The whitespace changes make it difficult to spot the single change, but checking model_info is not none before trying to use it (and giving a useful error message when it is) is a good change.

@computermacgyver
Copy link
Contributor

The items you've noted @DGaffney are good points --- let's not those in new JIRA tickets. I think we don't need to address them in this PR, however, since they are preexisting and unchanged except for whitespace.

Copy link
Contributor

@computermacgyver computermacgyver left a comment

Choose a reason for hiding this comment

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

Let's please make this two separate PRs. We should make the one line change and merge that without any further whitespace changes. I'm concerned otherwise that git blame will not work well and we'll confuse ourselves in the future about why we edited lines xyz.

Separately, we could have a different PR that fixes whitespace across the whole project?

computermacgyver pushed a commit that referenced this pull request Oct 25, 2023
@computermacgyver
Copy link
Contributor

Was planning to open a clean PR but accidentally committed to develop rather than the new branch. I'm inclined to leave that unless anyone has issues. Sorry. Need to wake up!
bd14839

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.

3 participants