Http: superfluous response.WriteHeader call from (routers.go:88)

After calling to endpoint : ConstructionParse

I got this error from my server

Parse successfully &{[0xc000072c00 0xc000072c60] [] map[amount:0 data:[] gas_limit:10000000 gas_price:250000000 recipient:0x3e2ead41200C971a3904438e1820FE4E6D7fB7f6 sender:0x17F2beD710ba50Ed27aEa52fc4bD7Bda5ED4a037]}
2020/11/02 17:30:55 POST /construction/parse 154.289µs
2020/11/02 17:30:55 POST /block 215.171862ms
2020/11/02 17:30:55 POST /block 216.647753ms
2020/11/02 17:30:55 http: superfluous response.WriteHeader call from (routers.go:88)

Log from rosetta-cli

2020/11/02 17:30:55 ERROR /construction/parse error:{"err":{},"client_err":null}
2020/11/02 17:30:55 check:construction status server shutting down
[MEMORY] Heap: 1334.069550MB Stack: 0.718750MB System: 1459.922035MB GCs: 4

Error: Operation.Type is invalid: 0: operation type is invalid in operation 0 unable to parse operations: /construction/parse: unable to parse unsigned transaction: unable to create transaction

Thanks for reporting this @nguyennguyen. I’ve seen this returned whenever the rosetta-cli forces exit when encountering an error during validation. It’s on our backlog of items to fix as a non-blocking item.

You should consider the error returned here as “valid” even though the “superfluous” log was printed. What this means is that your /construction/parse implementation is returning some Operations with types you did not define in your /network/options response.

Hi @patrick.ogrady,
is there any other possible reason ?
My /construction/parse return Operation Type 0
I also defined in network options

	TRANSACTION_TYPE_NAME = map[int32]string{
		0: "transfer",
		1: "in_contract_transfer",
		2: "gas_fee",
		3: "reward",

0 means native transfer

Why are you mapping operation types to integers and/or using these integers during construction? Very curious if you read any documentation somewhere that gave the impression that this was recommended? From the looks of it, the error you are getting is directly related to using this “mapped” representation:

Operation types (whether in /block responses or in construction) must use the strings you define in your /network/options response (not any mapping to them). In your example, this means using "transfer" directly instead of 0.

So that I can help debug, would you mind sharing the output of /network/options? The /network/options response for allowed operation types (NetworkOptionsResponse.Allow.OperationTypes) should just be an array of strings (not a map):

This could look something like:

    "operation_types": [

oh, my bad
Thank @patrick.ogrady for pointing it out

1 Like