Yes, I believe. We have made the test 2 or 3 times, restarting the front gateway.
We tested with different tags and it seems to be reproductible.
There is no issue with local tags.
I wasn't able to reproduce this with a pair of fresh 8.1.23 gateways. It's possible there's something in your setup that I'm missing in my replication attempt though. Reaching out to support so they can take a look at your system would probably be a good idea.
I am also unable to replicate with what I have been trying, including testing with auditing on and off for a project (remote and local auditing profiles).
Some other questions:
Are all gateways on 8.1.23? If not, which Gateway has 8.1.23 (one with the tag, or the one making the call?) and what is the version of Ignition running on the other Gateway?
Where is the system function being called from? Script Console, Perspective, Vision, Gateway Event Script?
I don't have the issue when I disable the audit.
All the gateway are in 8.1.23.
The script is executed by a Perspective message handler of a view.
I suspect something relative to the audit.
We use a custom audit module build by Travis initially for 7.9 to support audit splitting to multiple destination.
We have purchased the source of this module and we have adapted it for 8.0 and 8.1.
I will search if the issue could be on our side and try to reproduce the issue installing IA audit module.
So, I'm pretty sure I understand why this is happening.
First, 8.1.23 now actually audits writeAsync calls that happen from Perspective.
Since this is an async call, the audit is happening in the callback from TagProvider::writeAsync. For a remote provider, there's a single thread callbacks are executing on. Your audit logic is now being reached inside the callback while on that single thread.
You're then doing a blocking read inside that callback, presumably for a tag on the same remote provider, but that single thread is currently busy and you've essentially just live-locked yourself.
This doesn't happen with the writeBlocking call because the audit call happens after TagProvider::writeAsync has returned results, not inside the callback that it completed.
We'll need to discuss internally what should change, if anything, but for now you'll have to somehow not block on a result from the same provider in your audit logic.
Yeah, I think we'll be fixing this. It's essentially the same problem fixed for standard tag providers back in 8.1.13, under the release note:
Fixed a bug that lead to timeout when calling system.tag.readBlocking inside the callback for system.tag.readAsync.
and you can reproduce this without any audit logic at all, custom or not, by doing a system.tag.readBlocking for a tag in the same remote provider inside the async callback for the system.tag.writeAsync to a tag in that remote provider.
Thanks a lot for these detailed explanation and for pointing me to the root cause of this issue.
I will try to decouple and call readBlocking ouside the writeAsync context.