Why is action 'eosio::setcode' on the action blacklist in the mainnet?

Question

Error 3130005: Action to execute is on the blacklist Error Details: action 'eosio::setcode' is on the action blacklist pending console output:

in mainnet

Why is this?

Answer 1

It was mentioned on the Telegram channel for developers that a bug has been found, so the BPs blacklisted the command until it's fixed. No other details were provided for now, but some BPs mentioned that a more detailed report should be coming soon. There's also an issue raised on GitHub about this.

---

Post-mortem explanation thanks to Kevin Rose from EOS New York who saved Bart Wyatt's explanation from July 26th:

Now that mainnet is safe I can provide more details. Several versions ago we subjectively disabled implicit re-scheduling of deferred transaction because they did not properly refund RAM. That also disabled a pretty nasty bug that we were unaware of until yesterday. 1.1.1 fixed a source of non-determinism but in doing so, changed the behavior of a corner case in processing such that 1.1.1 producers could make blocks that appeared to reschedule a deferred transaction to 1.1.0 producers. This lead to those producers thinking that a later block was invalid (due to the nasty bug). It was a razor thin edge case so, of course jungle hit it.

To make matters worse, the order in which jungle producers were set up created a stubborn forking scenario where the 1.1.1 producers were able to convince themselves of a superior chain despite it being the minority fork so they never rejoined concensus and the 1.1.0 producers thought the superior chain was invalid due to a bad block. It will take them a while to coordinate and select a proper main chain. Until those producers all upgrade to 1.1.1 it can happy again

And the last part of their issue is that there is some additional historical block made by a 1.1.0 producer (or earlier) that is failing replay on 1.1.1 . We saw no such blocks in the mainnet and they are not producible by 1.1.1 so, again mainnet is safe. Had we seen that before the release or on mainnet we would have tried to address it before patch but, replaying jungle was not yet on our acceptance tests (it will be now, as well as other busy community testnets)”

The two releases referenced in the above: July 17th - https://github.com/EOSIO/eos/releases/tag/v1.1.0 July 24th - https://github.com/EOSIO/eos/releases/tag/v1.1.1

The following was listed as a critical issue in the v1.1.1 release notes. Self-Cancelling Deferred Transactions Calling cancel_deferred(sender_id) using the sender_id of the currently executing deferred transaction was not properly handled. This has been resolved so that the cancel_deferred call semantics match the expectation that passing invalid or already-retired sender_id is a no-op. The currently executing transaction is considered "retired" WRT these semantics. Unit test added https://github.com/EOSIO/eos/blob/083935ea0e4fa93e1a4a101164fe3e6182c8fcac/contracts/test_api/test_transaction.cpp#L321-L339

https://github.com/EOSIO/eos/commit/083935ea0e4fa93e1a4a101164fe3e6182c8fcac