The readResourceForUpdate impl makes a few assumptions regarding the fact that a given Resource represents persistent config (i.e. Resource.isRuntime() == true): 1) It calls rejectUserDomainServerUpdates() which means an OSH running on a server could not call this. 2) It calls authorize(false, READ_WRITE_CONFIG) which means an OSH for an op available to the RBAC Operator role could not call this. Places this impacts include LogStoreProbeHandler and LogStoreTransactionDeleteHandler which should be calling readResourceForUpdate but aren't – and can't because of this bug.
Refactored release note text for this as a Known Issue (ER4 fixes will not be picked up in the 6.3.0 Beta release) Original note included here for use at 6.3.0 GA: The operation execution logic assumes all management resources represent persistent configuration when handling the `readResourceForUpdate` method for an `OperationStepHandler`. As a result, the `subsystem=transaction/log-store=log-store` resource's 'probe' operation and the `subsystem=transaction/log-store=log-store/transactions=*` resource's 'delete' operation cannot be invoked by an admin in the 'Operator' role. To fix this, the operation execution logic now checks the Resource or, if necessary, its `ManagementResourceRegistration` to see if it is a runtime-only resource. The operations can be invoked by a user in the Operator role.
OK, the code is clearly there in 6.3.0.ER4 so I'm marking this as verified. But invoking /subsystem=transactions/log-store=log-store:probe on 6.3.0.ER3 by a user in the Operator role (RBAC enabled etc.) is by all means possible and results in {"outcome" => "success"} (on a fresh new install in the standalone-full profile), so the doc text is worth a revision.