Tx silently fails if payload is too large but shows up as succesful

[kaustavha]

Hi there,

I'm attempting to jam a ton of text into a smart contract on the rinkeby network. (~12kb).
The contract in essence takes text supplied and concats it to its internal data variable.
When I try to shove the whole 12kb payload in a single TX it fails silently while showing a succesfully mined TX.
But if I break it up into smaller TXs it works till 4605 bytes at least.
I chunked the whole text blob into 3. Attempting to send the TX with the s3 sized payload fails silently, but shows up in metamask as succesful. The other two work fine.

s3.length
4794
s2.length
3031
s1.length
4605

Here is the contract code:

import "github.com/Arachnid/solidity-stringutils/strings.sol";

contract PermanentDataStore {
    using strings for *;
    string public data;
    function PermanentDataStore(string _data) public {
        concat(data, _data);
    }
    
    function get() constant returns (string) {
        return data;
    }
    
    function add(string _data) public {
        concat(data, _data);
    }
    
    function clear() public {
        data = "";
    }
    
    function concat(string s1, string s2) {
        data = s1.toSlice().concat(s2.toSlice());
    }
}

I'm wondering what the limit is and if it is documented anywhere?
Also would it be possible to alert when it fails?

Expected behaviour would be either an alert that there was an issue, or a block that prevents initiating a tx with a payload too large.

Browser is chrome 59. OS is macOS 10.12.

Steps to reproduce:

• Deploy the contract on rinkeby.
• Generate a 12kb blob of text.
• Try calling contract.add(string) from the browsers console with various sized chunks of text.

[danfinlay]

Somewhat related to #1519, the issue here is that MetaMask only renders & represents submission-related errors, not contract failures.

Representing on-chain errors is a bit more complicated, it's definitely possible, but it can be an amount of time later, so an alert could seem out of nowhere, although it's probably relevant to a user whenever one of their transactions experiences an error, so that makes sense to me.

Kind of a two part solution then:

• Render on-chain errors (I swear this is a duplicate but can't find the other issue right now)
• Display a notification to users when one of their transactions fails (new idea! nice!)

[danfinlay]

Closing now as a duplicate of #1953 and #1952