milleruntime commented on code in PR #2755:
URL: https://github.com/apache/accumulo/pull/2755#discussion_r891237960
##########
core/src/main/java/org/apache/accumulo/fate/AdminUtil.java:
##########
@@ -390,11 +390,10 @@ private FateStatus getTransactionStatus(ReadOnlyTStore<T>
zs, Set<Long> filterTx
zs.unreserve(tid, 0);
- if ((filterTxid != null && !filterTxid.contains(tid))
- || (filterStatus != null && !filterStatus.contains(status)))
- continue;
-
- statuses.add(new TransactionStatus(tid, status, debug, hlocks, wlocks,
top, timeCreated));
+ if ((filterTxid == null) || filterTxid.contains(tid) || (filterStatus ==
null)
+ || filterStatus.contains(status)) {
+ statuses.add(new TransactionStatus(tid, status, debug, hlocks, wlocks,
top, timeCreated));
+ }
Review Comment:
> That's reasonable, but they way it was working was that if you provided a
txid and a status, you would get the txid if it matched and any fates that
matched that state regardless of the txid.
Working in a prior released version? like 1.10? If that's what the behavior
was the we should preserve the current behavior.
> With this version, you could look for a specific txid as long as it was in
a stage say txid = 0 and IN_PROGRESS, that seemed better than txid = 0, and all
other fates that are IN_PROGRESS
I don't follow you. I don't think the user will be able to search on txid =
0. One of the first things FATE does is create the txid.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]