-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AirbyteLogMessage.stack_trace
for logging messages with related (non-fatal) errors
#16479
Conversation
/test connector=connectors/source-faker
Build PassedTest summary info:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding from our IRL convo @evantahler was we wanted to a way to do structured logging, and that adding a generic data
field would allow us to do that. Why has this goal changed? It seemed like a worthwhile target. It seems the main reason was to prevent consumers from making assumptions about the structure of the logs, but I guess I don't see why that is any more true than it is today? (people can make assumptions about the content of the message
field)
I thought the previous direction made sense, so I'm just trying to better understand the change
@sherifnada yeah, this is a reversal. We ended up deciding that the right path forward was to be a strictly typed as possible with the protocol in order to discourage un-expected use cases. A single "stack_trace" property we can guarantee, and because it's a known term, expect people will use it only for this purpose. The "data" blob appeared to be to enticing for others to put structured data into it what would be used downstream (e.g. parse the logs for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
no comments about the protocol change itself, looks like it aligns with the slack discussions over the last few days. Minor comment about the implementation but I wouldn't block on it.
airbyte-workers/src/main/java/io/airbyte/workers/internal/DefaultAirbyteStreamFactory.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rationale seems fair enough
Is there a protocol change log that needs to be updated or something?
There isn't! I'll add one in a separate PR. There might be some conversation about the version numbers. Edit: That PR is here - #16560 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/publish connector=connectors/source-faker
if you have connectors that successfully published but failed definition generation, follow step 4 here |
/test connector=connectors/source-faker
Build FailedTest summary info:
|
/test connector=connectors/source-faker
Build FailedTest summary info:
|
/test connector=connectors/source-faker
Build PassedTest summary info:
|
/publish connector=connectors/source-faker
if you have connectors that successfully published but failed definition generation, follow step 4 here |
…n-fatal) errors (airbytehq#16479) * Test log message from faker * AirbyteLogMessage gains stack_trace * Fixup spacing * bump python protocol * fixup additionalProperties in faker spec * bump faker version * update docs * use lineSeparator vs \r\n * auto-bump connector version [ci skip] Co-authored-by: Octavia Squidington III <octavia-squidington-iii@users.noreply.github.com>
…n-fatal) errors (airbytehq#16479) * Test log message from faker * AirbyteLogMessage gains stack_trace * Fixup spacing * bump python protocol * fixup additionalProperties in faker spec * bump faker version * update docs * use lineSeparator vs \r\n * auto-bump connector version [ci skip] Co-authored-by: Octavia Squidington III <octavia-squidington-iii@users.noreply.github.com>
This PR is inspired by the conversation in #15668 (comment). Please read this thread first. The goal of this PR is to allow connectors to pass non-fatal stack traces along with an
AirbyteLogMessage
to be logged by the worker. This is helpful when the connector catches an exception and handles it, e.g.log("caught HTTP exception, trying again in 10 seconds", exception);
. The message and exception will be logged together for debugging.For example:
Will be rendered in the logs like:
This PR replaces #16317.
Rationale
AirbyteLogMessage
because this one additional named property's use-case is very clear and unlikely to be misinterpreted.AirbyeteLogMessage.data
) because people will do silly with things that we can’t guarantee - e.g. data.foo could be used for triggering other operations which we can’t promise will work in the future.stack_trace
as a first class object. This elevates this concept above a wildcard .data objectAirbyteErrorTraceMessage
so we will use the underscoreAirbyteNotificaitonTraceMessage
to remain reserved for notifying UI consumers of connector behavior.Notes
As this is a change to the Airbyte Protocol, do not merge this PR until the Protocol Change Process has been completed.
To test this PR,
source-faker
has also been modified to emit additional LOG messages.We use
stack_trace
(underscore) in the protocol.