Origin: Transaction failure

[mikeshultz]

Another exchange-exec-fail when doing a swap... This is on appers to be creating a proxy and doing a swap with 1m gas limit. The client reported an out of gas error, but etherscan doesn't really agree. A parity debug trace shows one with Bad jump destination, thought might be a side effect.

0x96880e15274ee05e242adfa2615140a410da169a96960393b6ee9a99f9045391

{ blockHash:
   '0x003f5b7e94dab991064df8b7a6174bf44ce8600de840c9da42a4795ef382ab10',
  blockNumber: 8514734,
  from: '0x84294BB21adc7D5204c8a367C8416b6422f2BCfd',
  gas: 1000000,
  gasPrice: '15000000000',
  hash:
   '0x96880e15274ee05e242adfa2615140a410da169a96960393b6ee9a99f9045391',
  input:
   '0xc0394af1000000000000000000000000b8b530afcfc283ee330f9fcaea26468c4007c0c3000000000000000000000000000000000000000000000000000000000000008000000000000000000000000084294bb21adc7d5204c8a367c8416b6422f2bcfd000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002a4036c878100000000000000000000000084294bb21adc7d5204c8a367c8416b6422f2bcfd000000000000000000000000819bb9964b6ebf52361f1ae42cf4831b921510f900000000000000000000000000000000000000000000000000000000000000e000000000000000000000000009cabec1ead1c0ba254b09efb3ee13841712be14000000000000000000000000000000000000000000000000000000000000022000000000000000000000000089d24a6b4ccb1b6faa2625fe562bdd9a232603590000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000010451b182500000000000000000000000000000000000000000000000000000000000000c360005b638eb2a0af0942e7f3f7af6637531c8ef334bd93000c948c8094d754c3600000000000000000000000000000000000000000000000000000000001275000000000000000000000000007ad0fa0e2380a5e0208b25ac69216bd7ff206bf800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000de0b6b3a764000000000000000000000000000089d24a6b4ccb1b6faa2625fe562bdd9a2326035900000000000000000000000064967e8cb62b0cd1bbed27bee4f0a6a2e454f06a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000446b1d4db70000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000005d76134f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
  nonce: 25,
  r:
   '0xabb713ebdc5d16539d464db0a67fbe5acc66e21e95391e5ebdfee7ed057cf1d7',
  s:
   '0x2bb541420bd174d675d8e6055ebc2a0bb8b74023326b95425a7c75675d428d7',
  to: '0x117793CC0b19C01c531638a986923533f2F865E7',
  transactionIndex: 121,
  v: '0x25',
  value: '5813218636572986' }
{ blockHash:
   '0x003f5b7e94dab991064df8b7a6174bf44ce8600de840c9da42a4795ef382ab10',
  blockNumber: 8514734,
  contractAddress: null,
  cumulativeGasUsed: 6912363,
  from: '0x84294bb21adc7d5204c8a367c8416b6422f2bcfd',
  gasUsed: 965459,
  logs: [],
  logsBloom:
   '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
  status: false,
  to: '0x117793cc0b19c01c531638a986923533f2f865e7',
  transactionHash:
   '0x96880e15274ee05e242adfa2615140a410da169a96960393b6ee9a99f9045391',
  transactionIndex: 121 }
============
0x96880e15274ee05e242adfa2615140a410da169a96960393b6ee9a99f9045391
--> 1. createProxyWithSenderNonce
{ _mastercopy: '0xb8B530afcfc283EE330F9FcaEa26468c4007c0C3',
  initializer:
   '0x036c878100000000000000000000000084294bb21adc7d5204c8a367c8416b6422f2bcfd000000000000000000000000819bb9964b6ebf52361f1ae42cf4831b921510f900000000000000000000000000000000000000000000000000000000000000e000000000000000000000000009cabec1ead1c0ba254b09efb3ee13841712be14000000000000000000000000000000000000000000000000000000000000022000000000000000000000000089d24a6b4ccb1b6faa2625fe562bdd9a232603590000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000010451b182500000000000000000000000000000000000000000000000000000000000000c360005b638eb2a0af0942e7f3f7af6637531c8ef334bd93000c948c8094d754c3600000000000000000000000000000000000000000000000000000000001275000000000000000000000000007ad0fa0e2380a5e0208b25ac69216bd7ff206bf800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000de0b6b3a764000000000000000000000000000089d24a6b4ccb1b6faa2625fe562bdd9a2326035900000000000000000000000064967e8cb62b0cd1bbed27bee4f0a6a2e454f06a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000446b1d4db70000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000005d76134f00000000000000000000000000000000000000000000000000000000',
  _owner: '0x84294BB21adc7D5204c8a367C8416b6422f2BCfd',
  saltNonce: '0' }
--> 2. swapAndMakeOffer
{ _owner: '0x84294BB21adc7D5204c8a367C8416b6422f2BCfd',
  _marketplace: '0x819Bb9964B6eBF52361F1ae42CF4831B921510f9',
  _offer:
   '0x51b182500000000000000000000000000000000000000000000000000000000000000c360005b638eb2a0af0942e7f3f7af6637531c8ef334bd93000c948c8094d754c3600000000000000000000000000000000000000000000000000000000001275000000000000000000000000007ad0fa0e2380a5e0208b25ac69216bd7ff206bf800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000de0b6b3a764000000000000000000000000000089d24a6b4ccb1b6faa2625fe562bdd9a2326035900000000000000000000000064967e8cb62b0cd1bbed27bee4f0a6a2e454f06a',
  _exchange: '0x09cabEC1eAd1c0Ba254B09efb3EE13841712bE14',
  _swap:
   '0x6b1d4db70000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000005d76134f',
  _token: '0x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359',
  _value: '1000000000000000000' }

CC @micahalcorn @DanielVF @tomlinton @franckc

[DanielVF]

@mikeshultz This looks to be intentionally reverting on a comparison with a block timestamp. My initial guess then is that this is happing because the deadline we are setting on the ethtotokenswapoutput uniswap method has expired by the time the transactions goes through.

https://docs.uniswap.io/smart-contract-api/exchange#ethtotokenswapoutput`

[franckc]

@DanielVF You are so incredible at debugging those contract errors. Are there any side effects to extending this deadline ?

[mikeshultz]

@DanielVF, thank you. I was sitting here coming up with an attrition-based battle plan and you drop in here in under 2 hours with a solid answer!

I think you presented these tools you took the screenshots from before in a weekly meeting. Mind sharing them again?

[DanielVF]

@franckc Should be no ill effects to pushing the deadline further out.

@mikeshultz Will dig up and post debugging resources.

[mikeshultz]

So yeah, this kind of makes sense with the slowness of the network right now. Kind of odd there would be both time-based and a value based(ETH sent) path to revert, but this is good to know. I've had some transactions take 25 minutes in the last couple days. I'm wondering if we should push the deadline past that or let these fail.

Though letting it fail with 1m gas during a proxy deploy, swap, and offer might be a bad call. I'm kind of wondering if we shouldn't be splitting these operations up, though the UX would kind of suck for a user to have to wait for multiple transactions...

Either way, we need to choose an upper-bound for this deadline.

[mikeshultz]

currently at ~5 minutes. Kind of wondering why we're using block timestamps at all?

https://github.com/OriginProtocol/origin/blob/519adbef38d20561eab7dbd3e192462c25b0c31a/packages/graphql/src/mutations/uniswap/swapToToken.js#L12

[franckc]

I don't see the advantage of this logic. I would rather simplify it and just use now.

300sec = 5min is a long time to wait. But given the Ethereum network is so slow those days, I don't see the risk or downside of extending the deadline to something much larger like 30min ?

[DanielVF]

I see what's going on here.

The local time could be off. Could be very, very off. So we can't rely on that, since it could have drifted many minutes/hours/days into the past.

We can't rely on the last block time either, for local usage, since it might have been a whole weekend since you last did an action that made a block get mined.

I think we could just Math.max() the two together. I don't think the case of having an absurdly long exchange deadline would be bad in any way. Or just take out the - 60 so it's clearer what is going on.

[mikeshultz]

Well, considering it's on mainnet and using block timestamps, local time should be irrelevant, no? Though I think the concerns over using local time are pretty valid. We probably can't even be reasonable assured that UTC time taken from the browser is valid. I guess that explains the use of block timestamps. Though even those can't be 100% trusted.

[franckc]

Good points. Let's just use max(latest block timestamp, local clock). I'll update the PR...