[ https://issues.redhat.com/browse/WFWIP-218?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on WFWIP-218: ---------------------------------------- Ok, after time of investigation I was able to reproduce the issue in standalone (non-kubernetes) setup (it happened to be a little bit complicated - at least for me - to understand what's happening here). The updated testcase is at: https://gitlab.mw.lab.eng.bos.redhat.com/ochaloup/tests-transactions/comm... the way to run is e.g. {code} export JBOSS_HOME=... mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Djbossts.noJTS -Dtest=TxPropagationJMSCrashRecoveryTestCase#injectRmfailAtServerCommit {code} The issue is caused by the fact that he recovery `commit` call has no information about the file system. The top-down-recovery runs with {{AtomicActionRecoveryModule}} which has no notion about {{XA}} specifics of the {{XAResource}}. The module just takes the serialized version of the resource and run commit on it. When the read of the serialized resource is done there is only information about the remote resource and thus the commit may succeed. The removal of the file of xa-recovery happens only at the second periodic recovery attempt when bottom-up {{XAResourceRecoveryModule}} calls {{recover}} and removes the record. This is a trouble when the remote server is already away (as it's for the scaledown) and the recover call keeps failing. That way there is no way for the WFTC to remove data on the second round of recovery during the {{XAResource.recover()}} call. The recover call fails forever and the WFTC xa recovery records resides at the place forever as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)