That's unfortunate, it would've cleared whatever misunderstanding with the previous batch transactions that you used to do.
Since it's not about the fee rate, it has to be calculated precisely from the mentioned values.
There's not even a fee rate in the transaction data, it's calculated by the client (Electrum) on-the-fly based from its size and left-over amount.

One possible case that I'm thinking is,based from the statement above: since it's automated, it might havehad been failing to broadcast the first few batch txns due to the low additional fee and saved as "local transaction".
The last batching transaction that hashad high fee causescaused those to be batched with enough fee. (since Electrum includes local transaction totransactions with it)
And since the local transactions aren't in any node's mempool, only the first transaction will subject to RBF's rule.

But since we have no data to analyze, the query can't be resolved.
Just take note that Electrum implemented RBF based from its unchanged standard and falling to do so will cause the transaction to be rejected by nodes.

That's unfortunate, it would've cleared whatever misunderstanding with the previous batch transactions that you used to do.
Since it's not about the fee rate, it has to be calculated precisely from the mentioned values.
There's not even a fee rate in the transaction data, it's calculated by the client (Electrum) on-the-fly based from its size and left-over amount.

One possible case that I'm thinking is, since it's automated, it might have been failing to broadcast the first few txns due to the low additional fee and saved as "local transaction".
The last batching transaction that has high fee causes those to be batched with enough fee. (since Electrum includes local transaction to it)

But since we have no data to analyze, the query can't be resolved.
Just take note that Electrum implemented RBF based from its unchanged standard and falling to do so will cause the transaction to be rejected by nodes.