get call_data and rename it

[InoMurko]

#1632

Overview

Get call data from fast exit contract and rename the fields so that we're able to use them.

Changes

Testing

[boolafish]

minor request, can we put the linked issue inside the code as comment or doc. People would totally get lost in the future potentially on this.

[unnawut]

Not well versed in this but notice that we had a separate ... [values]) when is_tuple(values) in the prior code.

Any chance we would get decode_function_call_result(%{function: "startExit"} = function_spec, [values]) and so the above function would catch the startExit before this one?

[InoMurko]

Not entirelly sure what you mean, so I'll address everything:
the values in this function clause is a list:

[
  1768000000000000,
  <<248, 124, 1, 225, 160, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 6, 71, 19, 191, 81, 112, 1, 246, 245, 1, 243, 148, 88,
    65, 40, 202, 209, 77, ...>>,
  <<199, 150, 50, 182, 108, 54, 104, 59, 238, 120, 114, 135, 4, 49, 219, 228,
    157, 221, 120, 21, 129, 53, 190, 121, 41, 240, 137, 122, 171, 246, 253, 247,
    78, 213, 192, 45, 109, 72, 200, 147, 36, 134, 201, 157, 58, 217, 153, ...>>,
  <<248, 179, 1, 225, 160, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 6, 68, 89, 65, 98, 64, 0, 248, 108, 245, 1, 243, 148,
    74, 104, 72, ...>>,
  <<11, 251, 191, 14, 56, 34, 69, 197, 207, 118, 133, 53, 9, 53, 58, 36, 248,
    60, 239, 202, 126, 239, 198, 16, 145, 115, 232, 115, 149, 11, 70, 34, 78,
    213, 192, 45, 109, 72, 200, 147, 36, 134, 201, 157, 58, ...>>,
  1767000000000001
]

where as in the top decode_function_call_result/2, its a list with a tuple:

[{<<248, 83, 1, 192, 238, 237, 1, 235, 148, 140, 7, 214, 39, 36, 232, 102, 145,
   82, 184, 199, 23, 67, 29, 135, 188, 216, 208, 23, 89, 148, 0, 0, 0, 0, 0, 0,
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...>>, 1000000000,
 <<248, 163, 1, 225, 160, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 59, 154, 202, 0, 248, 92, 237, 1, 235, 148,
   140, 7, 214, 39, ...>>, 0,
 <<248, 116, 1, 225, 160, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 59, 154, 202, 0, 238, 237, 1, 235, 148, 130,
   28, 224, ...>>, 0, 0, "",
 <<213, 14, 110, 137, 144, 125, 5, 4, 94, 64, 55, 85, 66, 96, 210, 166, 41, 110,
   42, 187, 199, 54, 83, 228, 31, 85, 4, 44, 153, 33, 56, 182, 104, 35, 67, 129,
   11, 98, 78, 229, 81, ...>>}]

the reason for that is that the input arguments in "startExit" are:

types: [{:uint, 256}, :bytes, :bytes, :bytes, :bytes, {:uint, 256}]

where as in others, they're tuples, for example "startStandardExit":

types: [tuple: [{:uint, 256}, :bytes, :bytes]]

[unnawut]

aha aha I see so startExit function signature should never fall into ..., [values]) when is_tuple(values) case