You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a36eab2
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ Console logs are more complete and readable. The SDK no longer replaces `window.
12
12
Network logs no longer hold responses in memory. The logger copied every `text/*` response and read the copy in full, so a server-sent events stream was buffered for the lifetime of the page and its connection stayed open after the app closed it. Streaming responses (`text/event-stream`, NDJSON, gRPC, `multipart/x-mixed-replace`) are now never read, other text responses are read from a copy up to 150 KB and the copy is then cancelled, and binary responses are not read at all (`[binary body omitted]`). Status, status text and response headers are recorded as soon as the headers arrive.
13
13
Network log entries are more accurate. URLs are logged absolute and methods upper case. Request headers passed as a `Headers` object (logged as `{}` before), a list of pairs or a `Request` are recorded, and request bodies from `URLSearchParams`, `FormData` (text fields plus file names and sizes), blobs, typed arrays and `Request` objects are logged as text. Failed requests (network error, abort, timeout) carry the error, e.g. `TypeError: Failed to fetch`. XHR requests now record response headers, log `json` responses as JSON instead of `<json>`, report aborts and timeouts, and a reused XHR no longer adds another set of listeners on every `open()`. Resource timing entries have the correct time, and requests made with a relative URL are no longer listed twice. Requests to blacklisted URLs, the SDK's own included, no longer take one of the buffered request slots.
14
14
Network log privacy settings apply more thoroughly. Props to ignore (from the dashboard and `Gleap.setNetworkLogPropsToIgnore`) are matched case-insensitively and removed from request and response headers, from JSON bodies at any depth (a dotted prop such as `user.password` also matches that path from the root), from form bodies and from URL query parameters. A body that is not valid JSON is no longer re-encoded as a JSON string. `Authorization`, `Proxy-Authorization`, `Cookie` and `Set-Cookie` header values are always replaced with `[REDACTED]`. The same rules and the URL blacklist now also apply to logs attached with `Gleap.attachNetworkLogs`. `setNetworkLogPropsToIgnore` and `setNetworkLogsBlacklist` replace their previous list instead of appending to it, the dashboard settings are replaced on every config refresh instead of piling up, and both lists apply together.
15
-
Fixed: the event stream (`/sessions/events`, which delivers `trackEvent`s, page views and session starts) could keep hitting an overloaded API and lost events. Each request carried the whole queue, which was emptied as soon as it went out, so the events of a failed request (429, 5xx, network error) were lost; after three failures it only paused until a fixed one-minute reset, a request that never answered blocked the stream, and an event whose data cannot be sent as JSON stopped it for good. Requests now only go out with a session, one at a time, give up after 30 s, and carry the oldest 100 events or about 256 KB at most; the rest follows right after a delivered request. After a 429, a 5xx, any other error answer, a network error or a timeout the events stay queued and the next request waits 3 s, then 6, 12, 24, 48 and at most 60 s (±20 % jitter), or longer when the answer has a `Retry-After` (seconds or an HTTP date, up to 5 minutes). Any 2xx answer delivers exactly the events it carried (events tracked in the meantime wait for the next request) and brings back the normal 2.5 s interval. The queue keeps at most 500 events; a session start is kept and the oldest other events make room. An event whose data cannot be sent as JSON is dropped instead of holding back the others.
15
+
Fixed: the event stream (`/sessions/events`, which delivers `trackEvent`s, page views and session starts) could keep hitting an overloaded API and lost events. Each request carried the whole queue, which was emptied as soon as it went out, so the events of a failed request (429, 5xx, network error) were lost; after three failures it only paused until a fixed one-minute reset, a request that never answered blocked the stream, and an event whose data cannot be sent as JSON stopped it for good. Requests now only go out with a session, one at a time, give up after 30 s, and carry the oldest 100 events or about 256 KB at most; the rest follows right after a delivered request. After a 408, a 429, a 5xx, a network error or a timeout the events stay queued (any other error answer, e.g. 400 or 413, drops them, so they cannot hold back the queue) and the next request waits 3 s, then 6, 12, 24, 48 and at most 60 s (±20 % jitter), or longer when the answer has a `Retry-After` (seconds or an HTTP date, up to 5 minutes). Any 2xx answer delivers exactly the events it carried (events tracked in the meantime wait for the next request) and brings back the normal 2.5 s interval. The queue keeps at most 500 events; a session start is kept and the oldest other events make room. An event whose data cannot be sent as JSON is dropped instead of holding back the others.
16
16
Fixed: the real-time connection (WebSocket) reconnected every 5 s after it dropped, forever and from every open tab in step, also while the browser was offline, and a reconnect still pending when the session changed (e.g. after `identify`) closed the new connection. Reconnects now wait 1 s, then 2, 4, 8, 16, 32 and at most 60 s (±20 % jitter). The wait starts over only after a connection stayed open for 10 s or received a message, so a server that accepts and closes connections right away is not retried every second. Only one reconnect is ever pending, and a new connection cancels it. While the browser is offline no reconnect is attempted; when it is back online the SDK reconnects right away. `Gleap.destroy()` now also closes the connection. The event stream only sends while connected, so its events stay queued until the connection is back.
0 commit comments