Greg Solovyev

Tagging @bleonard, @sherifnada and @davinchia for review

I like the approach. Please file Github issues for the first stage and include @davinchia and me as reviewers when creating PRs.

@bleonard @misteryeo any thoughts on @subodh1810 's comment above?

Moving to "blocked" until we decide if we should change this behavior

@VitaliiMaltsev we have only 1 Airbyte Cloud workspace with ES destination, so let's go with proposal B which follows the same pattern as all other connectors

> does this mean that anywhere else we use the LOGGER.log("message", e) call, it needs to be replaced by the ExceptionUtils.getStackTrace style? (that doesn't sound ideal) This does not sound...

I think the right solution is to use AirbyteTraceMessage with AirbyteErrorTraceMessage and to use custom JSON template (https://logging.apache.org/log4j/2.x/manual/json-template-layout.html ) to place error message and stack trace in the right fields.

Here's an example of log message template that preserves the stack trace: ``` { "type": "TRACE", "trace": { "type": "ERROR", "emitted_at": { "$resolver": "timestamp", "pattern": { "format": "%d{UNIX_MILLIS}", "timeZone": "UTC"...

@yurii-bidiuk the problem is that `AirbyteLogMessage` does not have fields to show stack trace, so either you need to use `AirbyteTraceMessage` or expand the protocol to include `AirbyteErrorTraceMessage` in `AirbyteLogMessage`....

@evantahler (cc @salima-airbyte ) I think adding `level` to `AirbyteErrorTraceMessage` would work as well, but I would probably make it reflect the log level coming from Log4J. I.e., it would...