Suggestion: This feels more like a "fake" than a "mock".

Note: Using limit/offset will get increasingly more slow as the table grows and you paginate further. First page will usually remain fast though.

Fine for now, though. Just raising awareness.

Considering we have both connect and disconnect enums andtype isnot part of this conflict handling, it suggests to me there is some gap in the logic. Considering connect/disconnect both share the same connection ID, we'll never write the disconnect but upsert the connect with close time and reason.

Either writing two entries, or doing a upsert, might make sense. But I think we have to ask what are we trying to achieve here and how are we looking to display the data?

My take as a user would be that I want to see two separate entries in the log, appearing in their chronological order. When viewing the connect, it would be an additional nice bonus to be able to see when the disconnect happened, and vice-versa that could simply be achieved by applying the connection ID as search filter.

EDIT: Correction, I was referring to "connection_action" (connect/disconnect), not "connection_type". But upon closer inspection that database type is not even used so it should probably be removed if not intended to be used.

That said, I want to clarify that I'm not concerned with whether or not we write two entries or upsert one, but in the latter case I do think we should make sure to "explode" the data when queried so that we can show the events in their chronological order.

EDIT: Correction, I was referring to "connection_action" (connect/disconnect), not "connection_type". But upon closer inspection that database type is not even used so it should probably be removed if not intended to be used.

Part of the reason forconnection_action is to better differentiateconnection_logs when they're output to thecoder server logs (the slog backend for the connection logger). Without including it on theInsertParams, for a connect + disconnect, you'd just see two logs, one withclose_time set, one without. The other reason is to ensure we don't incorrectly mark a connection as closed if an agent erroneously sent multipleconnect events with the same connection ID. I do agree to see it's weird to see a database type only used in a query and not in the database, but this seemed like the most appropriate way to handle both these cases.

I do think we should make sure to "explode" the data when queried so that we can show the events in their chronological order.

This is a good point. In my head I envisaged the final UI just including a duration on the table, the idea being that theconnection events were more important to the end user. Based off what I've heard of how users request / use this existing connection log data, I didn't think we'd be breaking any existing usecases by not showing disconnections intertwined with connections. Whilst I think we can explode the data in the query (and show connections and disconnection events chronologically), I'm not sure it'll play nice with pagination; i.e. you ask for offset 25, but instead of starting at the 26th disconnection or connection, your page starts after the most recent 25 connections.