Open 0x234 opened 4 years ago
POST /in_flight_exit.get_data HTTP/1.1
Content-Type: application/json
host: XXX
Content-Length: 473
Connection: close
{"txbytes":"0xf8d7f843b84106c1ee0eab776eb3d7dfa37781063a749e28651bc63b15e176407e8fc4d0de6933965955aaac555e4bdbabd432bdd179e487eb2560ebfc9fc9d427b3d2e05e691c01c58477359400f868f30194ca3e399bead9718cb147beada70816726064c14594000000000000000000000000000000000000000087b1a2bc2ec50000f30194d42b31665b93c128541c8b89a0e545afb08b7dd894000000000000000000000000000000000000000087b1a2bc2ec4fff6a00000000000000000000000000000000000000000000000000000000000000000","jsonrpc":"2.0","id":0}
HTTP/1.1 500 Internal Server Error
...
{"data":{"code":"server:internal_server_error","description":null,"object":"error"},"service_name":"watcher","success":false,"version":"0.3.0+fe94fbc"}
Logging and crashing is normal for elixir/erlang BEAM programs. In this case, only the request process died and was isolated crash. What needs to be done is:
defp find_single_input_data(input_utxo_pos, {:ok, {proofs, txbyteses, utxo_positions}}) do
input_utxo_pos
|> API.Utxo.compose_utxo_exit()
|> case do
{:ok, %{proof: proof, txbytes: txbytes}} ->
utxo_pos = Utxo.Position.encode(input_utxo_pos)
{:cont, {:ok, {[proof | proofs], [txbytes | txbyteses], [utxo_pos | utxo_positions]}}}
{:error, :utxo_not_found} ->
{:halt, {:error, :tx_for_input_not_found}}
end
end
Thanks! I just ran into this same thing during the Watcher exit load/perf testing too :(.
It is caused by an attempt to start an IFE using a spent deposit as an input. It is not what one normally would do, so the inability isn't hurting us terribly, but it definitely shouldn't crash and ideally should be made possible (for consistency, where IFEing from a spent non-deposit works just fine).
@pdobacz care to rename the issue to something that describes the problem appropriately?
Humans, I have a report in Sentry, that references this issue of yours!
Sentry issue: ELIXIR-OMG-21
Ay, I just realized there is a case for starting such an IFE, so I'll add some more priority to this. The use is where the IFE spends a spent deposit as one of its inputs and it is the other inputs that we're concerned about.
Here is an alice-bobbing scenario relevant:
(it is a variant of this)
So the endpoint in question should give all the necessary start IFE data, despite the deposit UTXO1m having been spent.