[ https://issues.redhat.com/browse/JBTM-3318?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3318: ---------------------------------------- This consists of timing issue where cancelling of the started LRA may come before LRA participant is enlisted. The exactly same trouble comes at issues with {{TckTests#timeLimit}}. I hoped that the fix of working with {{tck time factor}} will help (see https://github.com/eclipse/microprofile-lra/pull/309, https://github.com/jbosstm/narayana/pull/1623) but neither of that helped. The issue is not directly configurable with time factor, unfortunately. What happens on the Narayana AMS CI is that processing of the Quarkus coordinator and Thorntail TCK testsuite is slow. It happens that at time the {{@LRA}} method is invoked the JAX-RS filter starts the LRA, but meanwhile the timeout defined by {{timeLimit}} elapses (https://github.com/eclipse/microprofile-lra/blob/1.0-M1/tck/src/main/java...) and for the next step which is enlisting of the resource the LRA is {{canceled}}. The enlistment fails. Now, the failure is not deterministic as it could be {{412}} ({{precondition failed}}) in case there is still LRA on coordinator or {{404}} ({{gone}}) if the LRA was removed by recovery. In case of {{gone}} there is not thrown the exception in case of {{412}} there is thrown exception to client. What is needed is to find a way to adjust the {{timeLimit}} value based on the value of the tck timeout factor system property {{lra.tck.timeout.factor}}. That's a bit problematic as the annotation value is not adjustable during runtime easily. My PoC works with reflection on the classes: https://github.com/ochaloup/narayana/commit/9f8127a1a4c771f2fae8690a40f0b... -- This message was sent by Atlassian Jira (v7.13.8#713008)