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}}
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.
I have also seen this message on a standard alarm acknowledgement, even when trying to acknowledge one alarm at a time. However, we do have the same alarm table running on two different projects and clients. I'm wondering if there's an intermittent conflict between the timing of the two? 8.1.38.