CloudTrail Lake: the error message is not the code

Two fields, when both exist

A CloudTrail row can include an error code and an error message. The code is the short status the service logged. The message is the string that went with it. They can both be present. Quoting the message does not replace the code, and quoting the code does not let you rewrite the message in your own words and call it the field.

An empty code, when you have looked at the field, is a different fact from a missing message. Say which field you looked at.

A missing field stays missing

If the SELECT list did not include errorMessage, the result has no message. Do not compose one from the code. If the list did not include errorCode, do not reduce the message to a code you remember from another row. The statement decides which field you have.

A friendly sentence in the message is still the service’s string. It is not a conclusion that the call was harmless, and it is not a conclusion that it succeeded, if the code says otherwise. Cite the code for the status and the message for the wording.

What to file

File eventID, and errorCode and errorMessage only when they were selected and present, each labeled. If a field was not selected, say that. Do not file a paraphrase as if it were errorMessage.

Worked case: a sentence written for a code

A lab row’s errorCode is AccessDenied. The query did not select errorMessage. A draft adds “The sandbox user is not allowed to read this bucket” and labels it the error message. Those words are not on the row.

The note quotes errorCode AccessDenied and says errorMessage was not selected. The drafted sentence is removed. A follow-up query can select the message if the wording is needed, and that query gets its own id. This row does not gain a sentence.

eventID: <id>
errorCode: AccessDenied
errorMessage: not selected
draft sentence: removed
write: the code only
not: a message the query did not return