fixes possible error state in nautobot_ssot_duration_seconds metric

[Kircheneer]

Possibly fixes #248

[glennmatthews]

Do we understand the case in which job.job_class will be None? That generally shouldn't happen, though I think it's reasonable to add error handling in the case where it does.

[Kircheneer]

Do we understand the case in which job.job_class will be None? That generally shouldn't happen, though I think it's reasonable to add error handling in the case where it does.

Not quite - I want to explore this further with the user in #248 but IIRC its the second time I've seen it and I don't like the idea of breaking startup for people

[jdrew82]

Do we understand the case in which job.job_class will be None? That generally shouldn't happen, though I think it's reasonable to add error handling in the case where it does.

I believe this was seen with an SSoT Job that hadn't been updated to the 2.0 pattern. Technically the Job shouldn't have loaded/functioned at all from what I saw due to this. That's why I'm hesitant to do more than a simple check for the job_class attribute existing.

[Kircheneer]

I believe this was seen with an SSoT Job that hadn't been updated to the 2.0 pattern. Technically the Job shouldn't have loaded/functioned at all from what I saw due to this. That's why I'm hesitant to do more than a simple check for the job_class attribute existing.

That's all we're doing here though, isn't it?

[jdrew82]

I believe this was seen with an SSoT Job that hadn't been updated to the 2.0 pattern. Technically the Job shouldn't have loaded/functioned at all from what I saw due to this. That's why I'm hesitant to do more than a simple check for the job_class attribute existing.

That's all we're doing here though, isn't it?

You appear to be doing a try/except and catching a TypeError when I'd probably use hasattr(job, "job_class") instead personally.

[Kircheneer]

I believe this was seen with an SSoT Job that hadn't been updated to the 2.0 pattern. Technically the Job shouldn't have loaded/functioned at all from what I saw due to this. That's why I'm hesitant to do more than a simple check for the job_class attribute existing.

That's all we're doing here though, isn't it?

You appear to be doing a try/except and catching a TypeError when I'd probably use hasattr(job, "job_class") instead personally.

Got it, I think we can go for if job.job_class is None if you don't mind, I think that matches the core API as closely as possible. It will always have an attr as its a property

[jdrew82]

I believe this was seen with an SSoT Job that hadn't been updated to the 2.0 pattern. Technically the Job shouldn't have loaded/functioned at all from what I saw due to this. That's why I'm hesitant to do more than a simple check for the job_class attribute existing.

That's all we're doing here though, isn't it?

You appear to be doing a try/except and catching a TypeError when I'd probably use hasattr(job, "job_class") instead personally.

Got it, I think we can go for if job.job_class is None if you don't mind, I think that matches the core API as closely as possible. It will always have an attr as its a property

Works for me.

[Kircheneer]

Fixed!

[mzbroch]

FYI I pushed this (fix-#248) branch to fix248

It seems that poetry does not like # character in a branch name - it errors if referenced via git like below:

[tool.poetry.dependencies]
requests = { git = "https://github.com/kennethreitz/requests.git", branch = "next" }

[jdrew82]

LGTM!