docker run --rm -i -v /tmp/dev_root/workspace:/data -v /tmp/airbyte_local:/local -w /data/27/0 --network host airbyte/source-exchangeratesapi-singer-abprotocol:dev check --config tap_config.json
{"type": "LOG", "log": {"level": "INFO", "message": "Ping response code: 200"}}
{"type": "LOG", "log": {"level": "INFO", "message": "Check succeeded"}}

@Jared Rhizor (Airbyte) shouldn’t this be returning a

StandardCheckConnectionOutput

right now it is just returning loglines.

I thought the interface for this was the return code similar to singer.

I thought

StandardCheckConnectionOutput

was purely a UI model

oh maybe we said that.

how would we propagate error message though?

e.g. expired password.

if we just use the code

through log messages is what I was assuming

how would that work?

the check worker could convert the log lines to the

StandardCheckConnectionOutput.message

field?

which ones though?

do you have a link to the protocol doc?

errors?

i can’t find iit.

i don’t think this is a robust interface.

if the integration fails and wants to tell the user why, it should designate exactly what the message should be.

if you'd prefer a specific message, I'd want it to be defined as part of the protocol

it doesn’t make sense for the worker to guess at it by parsing logs.

and I'd prefer if it had optional messages per input field and a global one

should this check response extend

AirbyteMessage

?

or be separate

I guess separate

like how catalog is separate

yeah.

do you have access to the original protocl doc?

i can’t find this.

the original doc is https://docs.google.com/document/d/128xb33ZFbkPsxDPKmbRvrm1dSL265FUj3iK3XONKIlM/edit

I don't know where more up to date ones are

a lot has changed

i don’t remember their being a more up to date one. 😭

that’s why we’re out of sync 🤣

most of the conversation was on PRs

even in this old one it used logs and error code as a response though

i’ll put up an airbytecheckconnection message quickly now. then let’s go from there.

yep

it should have a dict for spec field name to error message and a global error message (all optional)

and of course the status enum

why not just a global error mesage?

eh. actually i see what you’re sayng.

willg vie it a try.

does that look okay?

yep

@charles are you going to actually make the sources return this object? if you aren't working on it I'll pick it up now

nope.

if you could do that that would be great.