Avoid persisting synthetic lobby-exit timestamp

This branch mutates shared latency state by writing client.lobby.exited = now when the event timestamp is missing, which can happen when queued/retried client.lobby.exited items are prepared after latencies were cleared (fresh evidence: batcher.js re-invokes prepareItem() in rerequest(), and prepareDiagnosticMetricItem() calls getStayLobbyTime(true) for that event). Once this synthetic timestamp is stored, later calls like getTotalMediaJMT()/getInterstitialToMediaOKJMT() can subtract an unrelated lobby duration and report clamped/incorrect media latencies for subsequent meetings.

Useful? React with 👍 / 👎.

it doesn't feel right to be saving a timestamp in a getter for latency. In general getters shouldn't change the state of a system, right? Could we maybe have a separate setter for the "client.lobby.exited" timestamp? Also I'm a bit confused why we need this in the first place, aren't the timestamps for all events saved already via the calls to saveTimestamp() from submitClientEvent()?

looks like you're right, we do saveTimestamp before prepareDiagnosticMetricItem gets called
i've also tested with logs to confirm this

Save the lobby-exit timestamp before populating stayLobbyTime

When client.lobby.exited is sent through the public fetch/keepalive path (buildClientEventFetchRequestOptions() / setMetricTimingsAndFetch()), this new case computes cdl.getStayLobbyTime() before that event’s timestamp has ever been recorded. submitClientEvent() records callDiagnosticLatencies.saveTimestamp({key: name}) in new-metrics.ts, but buildClientEventFetchRequestOptions() skips that and calls prepareDiagnosticMetricItem() directly, so the generated payload for client.lobby.exited ends up with joinTimes.stayLobbyTime unset. That means the new dedicated lobby-exit metric is silently missing in the unload-safe submission flow this SDK already exposes.

Useful? React with 👍 / 👎.

appears to not be an actual issue
the buildClientEventFetchRequestOptions path gets called when the client is about to be closed, if the user did exit the lobby before that, we'll have the timestamp, and if not, it's ok and expected that the stayLobbyTime will be undefined

@gabrielchl are you sure about this? I thought the whole point of buildClientEventFetchRequestOptions() was that it's called much earlier before user attempts to close the tab - I think it's called on meeting join, so that the metrics are prepared and can be sent quickly when tab is closed

Preserve original stayLobbyTime on retried lobby-exit events

If a client.lobby.exited batch is retried after a NetworkOrCORSError, MetricsBatcher.rerequest() re-runs prepareItem() on the same event. This branch recomputes stayLobbyTime from the shared callDiagnosticLatencies map, which Meeting.leave() clears and the next meeting repopulates. In the sequence “meeting A lobby exit -> network failure -> join meeting B -> retry”, merge() here will overwrite meeting A’s previously prepared stayLobbyTime with meeting B’s value, so the resent lobby-exit metric reports the wrong lobby duration.

Useful? React with 👍 / 👎.

Save the lobby-exit timestamp before reading stayLobbyTime

When client.lobby.exited is sent through the supported fetch/keepalive path, this case runs before any client.lobby.exited timestamp has been stored. CallDiagnosticMetrics.buildClientEventFetchRequestOptions() goes straight to prepareDiagnosticMetricItem() (src/call-diagnostic/call-diagnostic-metrics.ts:1367-1373), unlike NewMetrics.submitClientEvent() which first calls callDiagnosticLatencies.saveTimestamp({key: name}) (src/new-metrics.ts:371-376). Because getStayLobbyTime() now uses client.lobby.exited itself as the end timestamp, fetch-built lobby-exit events will always omit stayLobbyTime, so unload-safe submissions lose the metric entirely.

Useful? React with 👍 / 👎.