Log Transaction Codes and Operation Traces #228
Conversation
| case xdr.OperationTypeRestoreFootprint: | ||
| operationTraceDescription = operationTrace.RestoreFootprintResult.Code.String() | ||
| default: | ||
| return operationTraceDescription, fmt.Errorf("Unknown operation type: %s", operationTrace.Type.String()) |
There was a problem hiding this comment.
I think operationTrace.Type.String() would cause an error if the OperationType is bad.
// String returns the name of `e`
func (e OperationType) String() string {
name, _ := operationTypeMap[int32(e)]
return name
}
And operationTypeMap[int32(e)] would return a invalid key in map or something
There was a problem hiding this comment.
I thought this default error was designed to raise when the Operation Type is valid, we just haven't mapped it in our case statements. The behavior mirrors the way we define mapOperationType. My understanding is if the operationtype itself is bad, our code would already error and be unable to parse that operation.
There was a problem hiding this comment.
Do you want to change how we handle that in both functions? And if so, any guidance? Looks like the operation.Type.String() function does not return an error, so we don't have the ability to pass the error through
There was a problem hiding this comment.
My understanding is if the operationtype itself is bad, our code would already error and be unable to parse that operation
Ah you're right. I think the only time this would actually be a problem is if XDR was updated ahead of what stellar-etl is using. And most likely something else would error out before it even reached this point
Do you want to change how we handle that in both functions?
Nope it's fine as is
Adding transaction and operation level trace codes to stellar-etl. This gives a more detailed view into error reasons when a transaction fails to execute successfully.