A client is getting these errors when trying to acknowledge any alarms.
This is what the wrapper log reports:
An alarm could not be acknowledged. It may no longer be registered. Event details: 826ab271-10a9-4968-a09e-3c06a78b404d / {{ackUser=usr-prov:AdminsDB:/usr:nickm, eventTime=Thu Aug 25 11:50:20 ACST 2022}}
(@witman, looks like a log msg coming from you! 
)
Any ideas?
This is still present after upgrading to 8.1.20. Has anyone figured out what causes this?
We are seeing the same thing. Any resolutions?
We already moved the ack code to an asynchronous thread.
BUMPING for some insights?
I think I might have stumbled across a cause of this.
@PGriffith could you see if a client workstation having a time that is in the future compared to the gateway would cause this? We use scripting to ack alarms in the selected area, and I just saw this happening live so I could look into a bit.
I noticed the time in the log for the entries were in the future by two minutes compared to the gateway, went and checked the machine causing the errors and the time was in fact two minutes into the future.
If this is the case, my question would then be why would the local client time be used in place of the gateway time when acknowledging alarms?
I don't think anything about the timestamp would lead to this, but alarming isn't my area of expertise. That message goes into the logs when the set of IDs to acknowledge goes out, and not all of the UUIDs in the set are removed. Timestamps aren't relevant, as far as I know; the logged message is indicating there's a state mismatch (either you're trying to acknowledge something that no longer exists, or you're trying to ack something that never existed).
I would encourage you and anyone else in this thread with this issue to contact support officially, though.
Hello Team,
I have same issue with 8.1.28 version. Let me know if any resolution?
Still present in 8.1.38
