sdk: Lower client cache log severities

[kim]

Description of Changes

In particular, avoid logging entire rows above trace.

API

• This is a breaking change to the module API
• This is a breaking change to the ClientAPI
• This is a breaking change to the SDK API

If the API is breaking, please state below what will break

[kim]

On the fence re error! in this module: it's not really an error if we continue. Demote to warn! maybe?

[gefjon]

I agree with @Centril that the conditionals on log level clog the code in a way I don't love. I don't see much reason to offer the higher-level logs which don't include the row; it seems to me that these logs are useful only when debugging row representation and database state, so just knowing that some mysterious row was inserted/deleted/maintained seems unlikely to be useful.

I'd also appreciate being consistent about the log level: handle_row_update should log at trace the same as the other methods.

[gefjon]

On the fence re error! in this module: it's not really an error if we continue. Demote to warn! maybe?

I mean, any of the error logs denote a serious problem which will cause the client to behave wrong, most likely due to outdated module bindings. I think logging at error is reasonable. Honestly, likely all of these cases should exit the process.

[kim]

Honestly, likely all of these cases should exit the process.

Seriously? That does not seem like a viable option when using the sdk in a server context. Rather, I'd like to have some way of getting notified if / when some error state is encountered, so I can just throw away the client and re-initialize it.

[kim]

most likely due to outdated module bindings

Hm ok, if that can be inferred with some certainty, process::exit might be reasonable. But wouldn't some kind of ALPN be preferable?

[gefjon]

most likely due to outdated module bindings

Hm ok, if that can be inferred with some certainty, process::exit might be reasonable. But wouldn't some kind of ALPN be preferable?

As things stand now, both the module and the client must share a single canonical schema. With the tools we have now, recovering from a mismatch involves regenerating the client's module_bindings and recompiling the client. In the future I hope we'll have a better story (in particular this will be important once we get migrations), but for now there's not much we can do.

The only alternative to a schema mismatch I can think of is receiving corrupted data, which given that we communicate over TCP is also probably a world-ending (or process-ending) problem.

[kim]

Okay, so, if these are all fatal errors, how can I know they happened and terminate my process accordingly?

[kim]

We can move this discussion elsewhere if you prefer, but for what I'm doing I think I'd prefer those cases to cause a panic (perhaps feature-gated?). Except for connection errors, in which case it would be great to be able to reconnect.

[Centril]

I'll defer this review to @gefjon since they are the domain expert here.