Existing issues not being closed after instance roll

[mwarkentin]

👋 again

After resolving the previous issue which was blocking our sync w/ jira, we are noticing that we have old jira tickets which aren't being resolved. When we run a deploy, we push a new set of instances using a whole new AMI, rather than updating the OS in place. I'm not sure if this is contributing.

Here's an example jira which was created on april 16:

Halo detected sva issue in server prod-integproxy-app--i-0a23729ade516f185

Vulnerable package: accountsservice version 0.6.40-2ubuntu11.3

Critical: False
CVE-2018-14036 Score: 4.0 Supressed: False
Server prod-integproxy-app--i-0a23729ade516f185 at -unknown-

Here's a list of our currently active servers, you can see that there aren't any with a matching server id:

Any thoughts on how to handle this? I did retire the previous set of instances shortly after the deploy - is it possible this would've been picked up and resolved if the instances were just deactivated instead of retired?

Ideally, all issues related to instances which are no longer active should be resolved as part of the sync (I think).

[ashmastaflash]

@mwarkentin sorry to keep you waiting on a response.

Yes, all issues that are closed in Halo should be resolved on the Jira side with the next sync. Can you search in the logs from the integration for references to the IDs of the issues that aren't being closed? Are you seeing an attempted, but failing close? Or are they not coming up at all in the logs as subject to closure?

[mwarkentin]

I'll check into the logs tomorrow. :)

[mwarkentin]

Hi @ashmastaflash , I don't see any indication that it's trying to do anything with those IDs. Here's an example:

I'm wondering if it's skipping them due to the timestamp?

[mwarkentin]

I'm going to try setting the timestamp back before that issue was created and see if it syncs up.

[mwarkentin]

Didn't seem to pull in any more issues:

[mwarkentin]

Happy to hop on a call sometime today if you'd like to debug directly.

[ashmastaflash]

If the timestamp was moved forward to a point after when the issue was closed, then the integration would not have closed it. You could try setting the SSM timestamp back to just before the timestamp for issue closure and running the integration again, and see if it closes.

Are you seeing a common thread between all issues that haven't closed, like a window of time, or a specific type of issue?

[mwarkentin]

Resetting the SSM timestamp back to before the issue was created was what I attempted to do, but it didn't seem to pick up the issue even then, and then it "reset" the timestamp back to the current time.