Will 'x.send(amount)' revert if 'x' is a contract with a fallback function which reverts?

Question

I know that x.transfer(amount) reverts if either one of the following two scenarios takes place:

1. There is not enough ether in the calling contract, i.e., amount > address(this).balance
2. Variable x is the address of a contract with a payable fallback function which reverts

I know that x.send(amount) fails silently if the first scenario takes place.

But will it fail silently also if the second scenario takes place, or will it revert?

My overall purpose is to iterate a queue of (address wallet, uint256 amount) tuples, and for each tuple pay the given amount to the given wallet, until the queue is empty or my balance is too low.

So during this process, I am not concerned about failures due to insufficient funds.

I am, however, concerned about the possibility of a wallet being a contract with a payable fallback function.

If this function reverts, then this wallet will be stuck at the beginning of my queue forever, denying payment from the rest of my debt-owners.

So the only solution that I can think of is replacing transfer with send, but even this solution is very partial IMO, so I would be happy to hear alternative suggestions.

Thank you!

Answer 1

OK, the answer to my initial question is that x.send fails silently even if the fallback function of x reverts.

Here is the Truffle test (web3.js v0.20.6 if I remember correctly) that I conducted in order to conclude this:

On-chain code:

pragma solidity 0.4.25;

contract MyContract1 {
    uint256 public successCount;
    uint256 public failureCount;

    function() external payable {}

    function test(address wallet, uint256 amount) external {
        if (wallet.send(amount))
            successCount++;
        else
            failureCount++;
    }
}

contract MyContract2 {
    function() external payable {}
}

contract MyContract3 {
    function() external payable {revert();}
}

Off-chain code:

contract("Test", function(accounts) {
    it("Test", async function() {
        hMyContract1 = await artifacts.require("MyContract1").new();
        hMyContract2 = await artifacts.require("MyContract2").new();
        hMyContract3 = await artifacts.require("MyContract3").new();
        await printState(hMyContract1);
        await web3.eth.sendTransaction({from: accounts[0], to: hMyContract1.address, value: 1000000000});
        await printState(hMyContract1);
        await hMyContract1.test(hMyContract2.address, 1000000);
        await printState(hMyContract1);
        await hMyContract1.test(hMyContract3.address, 1000000);
        await printState(hMyContract1);
    });

    async function printState(hMyContract1) {
        let balance = await web3.eth.getBalance(hMyContract1.address);
        let successCount = await hMyContract1.successCount();
        let failureCount = await hMyContract1.failureCount();
        console.log();
        console.log(`balance = ${balance}`);
        console.log(`successCount = ${successCount}`);
        console.log(`failureCount = ${failureCount}`);
    }
});

Printout:

balance = 0 successCount = 0 failureCount = 0

balance = 1000000000
successCount = 0
failureCount = 0

balance = 999000000
successCount = 1
failureCount = 0

balance = 999000000
successCount = 1
failureCount = 1

So replacing transfer with send is an optional solution, but I still think that it's not a very good one, so I would be happy to hear alternative suggestions.

Answer 2

It's tricky.

You say you have debt owners and you have to repay quite a few. Ideally, this uses a withdrawal pattern and you avoid iteration altogether. I realize this is not always feasible. In cases like airdrops there can be a strong desire to use a use "push" process to send a batch of transactions. I'll assume there is a good reason.

On the contract side

You can iterate over a list of distributions and log success/fail as you go. You will want to use .send() so the whole process isn't held up by a single failed transaction. Since the sender has control of batch size, this is a case where you can use arrays for input and unbounded iteration. The sender can determine the optimal batch size. This is more gas-efficient than a purist approach insisting on one .send() per signed transaction.

The client is likely a server, but could be a browser, etc. Let's assume server. I mentioned earlier that the contract should emit success/fail while it thunders ahead undeterred by send failures. What to do with the send failures is a client-side concern, perhaps retry, perhaps a withdrawal pattern, perhaps give up. I merely assume the server needs to be informed.

On the sender side

A less obvious concern is nonce management. Whether batches or single transactions, to get significant volume through, the server and blockchain will probably use an asynchronous interface. That is, the server won't wait for confirmation before sending the next transaction. Consider deliberate throttling.

The server won't know the transactions were successful until sufficient confirmations are received. So there's the success/fail event and waiting for (10?) confirmations before declaring victory. I have found it's also important to have the ability to recall transactions that are overdue (maybe the gas was too low). You need to "recall" to have positive confirmation that the transaction is indeed failed and not merely indeterminant. This, so the server can confidently try again and be certain the end result won't be two payments to the same recipient.

In practice, this leads to a server that is tracking its pending transactions and their nonce perchance to emit a cancellation with the same nonce.

With so many pending transactions floating about, the client-side (say, geth) nonce is not reliable. Same for Infura. Pending transactions are subjective from the node perspective and a miss by even one will result in various errors and jam up the process.

In the end, you probably set up a singleton nonce counter of your own based on the idea that the sender is most qualified to know what was sent. More on the technical issues of infrastructure for this over here: Concurrency patterns for account nonce

Hope it helps.