A method and device for collecting a pre-crash communication state black box trace

Abstract

The application relates to the field of communication workbench running state diagnosis, in particular to a browser crash communication state black box tracing collection method and device, a brand-new page session ID is generated at each page loading, and the session state of the page is marked as active; during the page running, the latest heartbeat time of the page session is periodically refreshed; the communication workbench is subjected to state sampling, and the sampling data is asynchronously delivered to a background thread; when the page triggers a normal closing process, the session state of the page is marked as closed; when the page is reloaded, if the state of the previous session is active and the last heartbeat time has expired, it is determined that the previous session is abnormal; corresponding cache data in the ring buffer is searched through the page session ID of the previous session, and the application scheme realizes low-cost and high-reliable capture of the communication state and business context before the browser process-level crash, and realizes on-site restoration after the crash.

Description

Technical Field

[0001] This application relates to the field of communication workbench operational diagnostics technology, specifically to a method and apparatus for tracing and collecting the black box of communication status before a browser crashes. Background Technology

[0002] In web workbenches (such as call center agent workbenches, unified communications consoles, and customer service ticketing systems) that include WebRTC (Web Real-Time Communications) audio and video communication, massive long-lived connections, complex state management, and multi-view interaction, unexpected browser tab crashes are among the most difficult online faults to locate. Users typically only report "the page suddenly went blank or crashed," making it difficult for developers to reconstruct the actual operating state before the crash, resulting in low troubleshooting efficiency. Existing front-end monitoring solutions mainly suffer from the following technical deficiencies: The instantaneous crash reporting mechanism has a blind spot: traditional solutions rely on exception handling interfaces such as window.onerror and initiate network reporting in real time when a crash occurs. However, when the browser rendering process exits instantly due to an OutOfMemoryError (OOM), a native engine exception, or a forced termination of the host environment, the main thread cannot execute any subsequent code, resulting in the complete loss of critical information about the situation before the crash.

[0003] The memory and communication states before a crash cannot be persistently retained: the application state (such as Redux state), WebSocket send and receive events, SIP (Session Initialization Protocol) signaling fragments, critical business actions, and memory change trends in the last few seconds before the crash only reside in memory. Once the process dies, this data is lost, making it difficult for troubleshooters to reproduce the triggering conditions or locate the root cause.

[0004] Writing to local storage frequently directly on the main thread can amplify the risks: if localStorage or synchronous writing on the main thread is used to record the state frequently, it will introduce serial I / O blocking, serialization overhead and rendering stuttering, and may even become a new factor that causes the page to freeze or crash.

[0005] Lack of a closed-loop mechanism for automatic data retrieval after a crash: Existing solutions focus on immediate reporting when a crash occurs, but lack a closed-loop mechanism that continuously retains the most recent time window data locally and automatically identifies abnormal exits, performs data retrieval and reporting after the page is reloaded.

[0006] Therefore, how to capture the communication state and business context before a browser process crash with low overhead and high reliability, and restore the scene after the crash, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0007] To capture the communication state and business context of a browser process before a crash with low overhead and high reliability, and to restore the scene after the crash, in a first aspect, embodiments of this application provide a method for tracing and collecting the black box of the browser's communication state before a crash, the method comprising: A brand new page session ID is generated each time the page loads, and the page session state is marked as active; during page operation, the most recent heartbeat time of the page session is periodically refreshed; The communication workbench is sampled for status, and the sampled data is asynchronously delivered to the background thread. The sampled data includes a lightweight global status snapshot of the communication workbench, key signaling logs, key user actions, and memory trend indicators. The background thread is used to store the sampled data in a circular buffer. When the page triggers the normal closing process, the page's session state is marked as closed; When the page is reloaded, the state of the previous session and the last heartbeat time on the page are read from the local persistent storage module. If the state of the previous session is active and the last heartbeat time has expired, it is determined that the previous session was abnormal. For pages that experience an anomaly, the corresponding cached data is searched in the circular buffer using the previous page session ID. The tail data before the crash is extracted in chronological order to form a continuous state sequence.

[0008] In one possible implementation, the asynchronous delivery of the sampled data to the background thread includes: The sampled data is asynchronously delivered to the memory buffer queue of the background thread, and the data to be written in the current batch is read from the memory buffer queue when the preset time interval or the queue length reaches the threshold. Calculate the monotonically increasing current global write sequence number for the current batch of data to be written, and map it to the fixed slot index of the circular buffer through modulo operation; Write the data to be written to the target slot indicated by the fixed slot index, while overwriting the historical records with smaller global write sequence numbers in the same slot.

[0009] In one possible implementation, the step of searching for the corresponding cached data in the circular buffer using the previous page session ID, and extracting the tail data before the crash in chronological order to form a continuous state sequence includes: Scan all slots in the circular buffer corresponding to the previous page session ID, sort the cached data in all slots in ascending order according to the monotonically increasing global write sequence number, and restore the sequential data that reflects the real time series. The sequential data within the preset window is acquired to form a continuous state sequence.

[0010] In one possible implementation, the method further includes: The continuous state sequence is subjected to desensitization, metadata encapsulation, and compression, and the processing results are uploaded to the monitoring server; the metadata includes browser version, operating system, page build version, user terminal hardware feature summary, and crash determination reason; After uploading, clear the cached data corresponding to the previous page session ID or mark the data as retrieved.

[0011] In one possible implementation, the state sampling of the communication workstation includes: For at least one of the following: lightweight global state snapshot, critical signaling log, key user actions, and memory trend indicators, periodic sampling or event-triggered sampling shall be used.

[0012] In one possible implementation, the method further includes: Extract a lightweight global state snapshot from the processing results, obtain the agent status based on the lightweight global state snapshot, and locate the stage of the service when the crash occurred. Extract key signaling logs from the processing results, and reconstruct the interaction timing of the communication protocol based on the key signaling logs; Extract key user actions from the processing results and determine the crash triggering action based on the user's operation path; Extract memory trend indicators from the processing results. If memory usage increases sharply before the crash, the cause of the crash is determined to be memory overflow.

[0013] In one possible implementation, the method further includes: Get the second page session ID, second session state, and second last heartbeat time of the reloaded page; Store the second page session ID, the second session state, and the second last heartbeat time in the local persistent storage module, and delete the previously stored previous page session ID, the state of the previous session on this page, and the last heartbeat time.

[0014] Secondly, embodiments of this application provide a device for tracing and collecting the black box of a browser's communication state before a crash, the device comprising: The initialization module generates a brand new page session ID each time the page loads and marks the page's session state as active; during page operation, it periodically refreshes the page session's most recent heartbeat time. The sampling module is used to sample the status of the communication workbench and asynchronously deliver the sampled data to the background thread. The sampled data includes a lightweight global status snapshot of the communication workbench, key signaling logs, key user actions, and memory trend indicators. The background thread is used to store the sampled data in a circular buffer. The session state update module is used to mark the session state of the page as closed when the page triggers the normal closing process; The determination module is used to read the status and last heartbeat time of the previous session on the page from the local persistent storage module when the page is reloaded. If the status of the previous session is active and the last heartbeat time has expired, it is determined that the previous session was abnormal. The source tracing module is used to find the corresponding cached data in the circular buffer by using the previous page session ID for pages that have encountered an anomaly, and extract the tail data before the crash in chronological order to form a continuous state sequence.

[0015] In one possible implementation, the sampling module is specifically used for: The sampled data is asynchronously delivered to the memory buffer queue of the background thread, and the data to be written in the current batch is read from the memory buffer queue when the preset time interval or the queue length reaches the threshold. Calculate the monotonically increasing current global write sequence number for the current batch of data to be written, and map it to the fixed slot index of the circular buffer through modulo operation; Write the data to be written to the target slot indicated by the fixed slot index, while overwriting the historical records with smaller global write sequence numbers in the same slot.

[0016] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned methods for tracing and collecting the black box of communication status before a browser crash.

[0017] This application provides a method for tracing and collecting the black box of communication state before a browser crash, comprising: generating a new page session ID each time the page is loaded, and marking the page session state as active; periodically refreshing the most recent heartbeat time of the page session during page operation; sampling the state of the communication workbench and asynchronously delivering the sampled data to a background thread; the sampled data includes a lightweight global state snapshot, key signaling logs, key user actions, and memory trend indicators in the communication workbench, and the background thread is used to store the sampled data in a circular buffer; when the page triggers a normal closing process, marking the page session state as closed; when the page is reloaded, reading the state and last heartbeat time of the previous session on the page from the local persistent storage module, if the state of the previous session was active and the last heartbeat time has expired, then determining that the previous session was abnormal; for the abnormal page, searching for the corresponding cached data in the circular buffer through the previous page session ID, extracting the tail data before the crash in chronological order to form a continuous state sequence. This application's solution achieves low-overhead and high-reliability capture of the communication state and business context before a browser process-level crash, and realizes on-site restoration after the crash. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a method for tracing and collecting the black box of a browser's communication state before a crash, provided in an embodiment of this application; Figure 2 A schematic diagram of the architecture of the black box tracing and collection method for the communication state before a browser crash provided in this application; Figure 3 This is a sequence diagram for crash detection, source tracing, and recovery. Detailed Implementation

[0019] In web workbenches (such as call center agent workbenches, unified communications consoles, and customer service ticketing systems) that include WebRTC (Web Real-Time Communications) audio and video communication, massive long-lived connections, complex state management, and multi-view interaction, unexpected browser tab crashes are among the most difficult online faults to locate. Users typically only report "the page suddenly went blank or crashed," making it difficult for developers to reconstruct the actual operating state before the crash, resulting in low troubleshooting efficiency. Existing front-end monitoring solutions mainly suffer from the following technical deficiencies: The instantaneous crash reporting mechanism has a blind spot: traditional solutions rely on exception handling interfaces such as window.onerror and initiate network reporting in real time when a crash occurs. However, when the browser rendering process exits instantly due to an OutOfMemoryError (OOM), a native engine exception, or a forced termination of the host environment, the main thread cannot execute any subsequent code, resulting in the complete loss of critical information about the situation before the crash.

[0020] The memory and communication states before a crash cannot be persistently retained: the application state (such as Redux state), WebSocket send and receive events, SIP (Session Initialization Protocol) signaling fragments, critical business actions, and memory change trends in the last few seconds before the crash only reside in memory. Once the process dies, this data is lost, making it difficult for troubleshooters to reproduce the triggering conditions or locate the root cause.

[0021] Writing to local storage frequently directly on the main thread can amplify the risks: if localStorage or synchronous writing on the main thread is used to record the state frequently, it will introduce serial I / O blocking, serialization overhead and rendering stuttering, and may even become a new factor that causes the page to freeze or crash.

[0022] Lack of a closed-loop mechanism for automatic data retrieval after a crash: Existing solutions focus on immediate reporting when a crash occurs, but lack a closed-loop mechanism that continuously retains the most recent time window data locally and automatically identifies abnormal exits, performs data retrieval and reporting after the page is reloaded.

[0023] Therefore, how to capture the communication state and business context before a browser process crash with low overhead and high reliability, and restore the scene after the crash, is a technical problem that urgently needs to be solved in this field.

[0024] First, the technical terms used in the text will be explained in a unified manner.

[0025] Black Box: Refers to the local persistent recording mechanism used in this application to continuously record the critical state of the browser before it crashes and to use for source tracing analysis after abnormal exit.

[0026] Circular Buffer: A fixed-capacity data structure that, once full, is filled with new records that overwrite the oldest ones. It is suitable for scenarios that only retain data from the most recent time window.

[0027] IndexedDB: Refers to the structured transactional local storage capability provided by browsers, which can be used to store large-scale structured records.

[0028] OPFS: Refers to Origin Private File System, a high-performance private file system implementation provided by the browser, suitable for background threads to perform high-speed local read and write operations.

[0029] Session ID: A unique identifier generated each time a page is launched, used to distinguish different browser sessions and the corresponding black box records.

[0030] Abnormal crash: refers to a state in which the process exits, the tab crashes, the browser is forcibly killed, or the browser terminates abnormally without going through the normal closing process.

[0031] Source tracing package: refers to the continuous data fragments extracted from the black box circular buffer before the crash, which are then sorted, de-identified, compressed, and have environmental metadata attached, forming the upload carrier.

[0032] Firstly, see [the following] Figure 1 This application provides a method for tracing and collecting black box data on the communication state before a browser crash, the method comprising: S101 generates a brand new page session ID each time the page loads and marks the page session state as active; during page operation, the most recent heartbeat time of the page session is periodically refreshed.

[0033] The main thread or background thread periodically updates the most recent heartbeat time to indicate that the page is still running normally.

[0034] S102, the status of the communication workbench is sampled, and the sampled data is asynchronously delivered to the background thread; the sampled data includes a lightweight global status snapshot of the communication workbench, key signaling logs, key user actions and memory trend indicators, and the background thread is used to store the sampled data in a circular buffer.

[0035] Collect the current page's runtime status data, specifically through the main thread deployed in the front-end core state stream, ReduxMiddleware, WebSocket interceptor, WebRTC event handler, or equivalent business entry point; periodically sample or event-triggered sample the lightweight global state snapshot, key signaling logs, key user actions, and memory trend indicators in the communication workbench; append a high-precision timestamp, session ID, data type identifier, and source module identifier to each sampled data, and then asynchronously deliver it to the background thread via postMessage.

[0036] The above-mentioned asynchronous delivery of sampled data to a background thread can specifically include: The sampled data is asynchronously delivered to the memory buffer queue of the background thread, and the data to be written in the current batch is read from the memory buffer queue when the preset time interval or the queue length reaches the threshold. Calculate the monotonically increasing current global write sequence number for the current batch of data to be written, and map it to the fixed slot index of the circular buffer through modulo operation; Write the data to be written to the target slot indicated by the fixed slot index, while overwriting the historical records with smaller global write sequence numbers in the same slot.

[0037] A Web Worker or equivalent background thread is used to receive sampled fragments delivered by the main thread and first put them into a memory buffer queue; within a preset throttling period, it performs batch serialization and transaction writing of the data to be written; it maintains a fixed-length circular buffer, preferably setting the maximum number of slots to MAX_SIZE, and the write position is calculated by writeIndex mod MAX_SIZE, thereby performing an overwrite update on the oldest record.

[0038] The main thread does not directly manipulate persistent storage; instead, it only generates lightweight event packets and sends them to the background worker. The background worker internally maintains a queue of events to be written and writes them to the circular buffer IndexedDB in batch transactions. Compared to the main thread's synchronous disk writing approach, this structure removes high-frequency serialization and I / O pressure from the page interaction thread.

[0039] As the number of records to be written continues to grow, the write engine operates according to the following logic: Read the current batch of data to be written from the memory buffer queue; Calculate the current global write sequence number and map it to a fixed slot index using a modulo operation; Write a new record to the target slot, while overwriting older historical records in the same slot; Update the last write time and write count for the corresponding session; After a transaction is successfully committed, wait for the next throttling cycle to continue processing new data.

[0040] This mechanism keeps the local data space constant and continuously retains the most critical state changes from the last N seconds.

[0041] In addition to IndexedDB, an equivalent implementation (OPFSOrigin Private FileSystem) can be used in a high-performance browser environment; each record includes at least a slot index, timestamp, session identifier, data type, payload summary, full payload reference, or compressed content; through a fixed capacity design, only state samples within the most recent time window are retained, and long-term full data preservation is not pursued.

[0042] S103, When the page triggers the normal closing process, the page's session state is marked as closed.

[0043] When the page triggers the normal closing process, it is preferable to change the session state to closed in the beforeunload, explicit page exit action, or equivalent cleanup node.

[0044] S104. When the page is reloaded, the state of the previous session and the last heartbeat time on the page are read from the local persistent storage module. If the state of the previous session is active and the last heartbeat time has expired, it is determined that the previous session was abnormal.

[0045] The local persistent storage module `localStorage` uses a fixed key to store the page session ID, session state, and last heartbeat time. If page A is currently running, then the stored data is the page session ID, session state, and last heartbeat time corresponding to page A. When page A is reloaded, the previously stored data is retrieved. If the session state is `closed`, it means no crash has occurred, and the local persistent storage module is updated by storing the page session ID, session state, and last heartbeat time corresponding to the reloaded page A, and deleting the previous content. If the session state is `active` and the last heartbeat timeout has occurred, it means a crash has occurred, and subsequent processes need to be executed. After execution, the page session ID, session state, and last heartbeat time corresponding to the reloaded page A are stored in the local persistent storage module, and the previous content is deleted. If the session state is `active` and the last heartbeat timeout has not occurred, it means that this is just a normal refresh, and subsequent processes do not need to be executed. The page session ID, session state, and last heartbeat time corresponding to the reloaded page A are stored in the local persistent storage module, and the previous content is deleted.

[0046] Traditional front-end pages can only reliably identify normal shutdowns, lacking recoverable judgment for abnormal crashes, process termination by the system, and unexpected freezes. This application establishes the following judgment rules through a local session state machine and heartbeat mechanism: When the page is initialized, a new session ID is written and its state is marked as active. During page operation, the most recent heartbeat time of the session is periodically refreshed; If the page ends normally, the session state is marked as closed; When the page is reloaded next time, read the state of the previous session and the last heartbeat time; If the previous session is still active and the difference between the most recent heartbeat time and the current time exceeds the preset crash threshold, it is determined to be an abnormal crash session; The black box data extraction and uploading process will only be triggered when the aforementioned conditions are met, in order to reduce false alarms.

[0047] The algorithm described above can identify typical OOM crashes, as well as abnormal closing scenarios caused by browser underlying abnormalities, rendering process exits, or tabs being abnormally terminated.

[0048] S105: For the page that has encountered an error, search for the corresponding cached data in the circular buffer using the previous page session ID, and extract the tail data before the crash in chronological order to form a continuous state sequence.

[0049] Scan all slots in the circular buffer corresponding to the previous page session ID, sort the cached data in all slots in ascending order according to the monotonically increasing global write sequence number, and restore the sequential data that reflects the real time series. The sequential data within the preset window is acquired to form a continuous state sequence.

[0050] After determining that an abnormal crash has occurred, a circular buffer corresponding to the SessionID is locked. Since the data stored in the circular buffer all contain the SessionID, valid records of the target session in all slots can be scanned; the set of records belonging to the abnormal session's SessionID is filtered out. Then, the tail data before the crash is extracted in chronological order from the oldest valid slot to the latest slot, forming a continuous state sequence. Since the global write sequence number has a monotonically increasing property, it can reflect the time order itself. Therefore, it can be sorted in ascending order based on the logical write sequence number or high-precision timestamp, and the most recent N seconds or the most recent M records can be extracted to form a continuous window before the crash. This continuous window is used as the main content of the traceability package.

[0051] With the above recovery strategy, even if the underlying layer uses a fixed slot overwrite method, the continuous state trajectory before the crash can be restored after restarting.

[0052] This application provides a method for tracing and collecting the black box of communication state before a browser crash, comprising: generating a new page session ID each time the page is loaded, and marking the page session state as active; periodically refreshing the most recent heartbeat time of the page session during page operation; sampling the state of the communication workbench and asynchronously delivering the sampled data to a background thread; the sampled data includes a lightweight global state snapshot, key signaling logs, key user actions, and memory trend indicators in the communication workbench, and the background thread is used to store the sampled data in a circular buffer; when the page triggers a normal closing process, marking the page session state as closed; when the page is reloaded, reading the state and last heartbeat time of the previous session on the page from the local persistent storage module, if the state of the previous session was active and the last heartbeat time has expired, then determining that the previous session was abnormal; for the abnormal page, searching for the corresponding cached data in the circular buffer through the previous page session ID, extracting the tail data before the crash in chronological order to form a continuous state sequence. This application's solution achieves low-overhead and high-reliability capture of the communication state and business context before a browser process-level crash, and realizes on-site restoration after the crash.

[0053] In one example, the method further includes: The continuous state sequence is subjected to desensitization, metadata encapsulation, and compression, and the processing results are uploaded to the monitoring server; the metadata includes browser version, operating system, page build version, user terminal hardware feature summary, and crash determination reason; After uploading, clear the cached data corresponding to the previous page session ID or mark the data as retrieved.

[0054] To ensure that the black box data is suitable for both troubleshooting and online uploading, this application preferably performs the following processing on the traceability package before exporting: Status snapshots, signaling logs, and resource usage metrics are categorized and organized according to data type. Sensitive fields such as mobile phone number, customer identifier, number details, and work order text are anonymized or summarized. Additional metadata includes browser version, operating system, page build version, summary of client hardware characteristics, and crash cause determination; The final upload package is generated using Gzip or an equivalent compression algorithm.

[0055] In this way, the system can retain sufficient traceability value while avoiding the direct uploading of excessive redundant content and sensitive information.

[0056] In one example, the method further includes: Extract a lightweight global state snapshot from the processing results, obtain the agent status based on the lightweight global state snapshot, and locate the stage of the service when the crash occurred. Extract key signaling logs from the processing results, and reconstruct the interaction timing of the communication protocol based on the key signaling logs; Extract key user actions from the processing results, and determine the crash triggering action based on the user's operation path; Extract memory trend indicators from the processing results. If memory usage increases sharply before the crash, the cause of the crash is determined to be memory overflow.

[0057] Specifically, the lightweight global state snapshot can determine whether the agent is on a call, which pop-up is currently open, and whether customer information has been loaded. Developers can immediately understand the business context before the crash by viewing the state snapshot. The interaction sequence of the communication protocol can reflect whether an incorrect SIP response was received or whether the WebSocket was abnormally closed before the crash. For call center and WebRTC scenarios, many crashes are related to signaling anomalies, and signaling logs can help determine whether the problem is with the peer or a front-end parsing error. Key user actions include clicking buttons, opening pop-ups, and submitting forms. Many crashes are caused by specific operation sequences, such as opening a billing window before switching agent status; user action records can help reproduce these crashes.

[0058] In one example, the method further includes: Get the second page session ID, second session state, and second last heartbeat time of the reloaded page; Store the second page session ID, the second session state, and the second last heartbeat time in the local persistent storage module, and delete the previously stored previous page session ID, the state of the previous session on this page, and the last heartbeat time.

[0059] In this way, the currently loaded page can obtain the previous session state and the last heartbeat time of the page.

[0060] In one example, a call center agent was handling a lengthy and complex multi-party call while simultaneously viewing a historical billing pop-up, a customer information sidebar, and a real-time quality control panel on their workbench. Due to an error in the billing pop-up loading excessively large pagination data, the browser's rendering process experienced a continuous increase in memory usage, ultimately triggering a page crash with a blank screen. Traditional front-end monitoring systems failed to capture the valid error message, and the development team was unable to pinpoint the cause from the real-time logs.

[0061] To address this issue, this application provides the following implementation steps: Silent sampling: When the browser page is running normally, the main thread state sampling probe collects a lightweight global state snapshot once per second, and generates incremental logs when key events such as SIP INVITE, ringing state switching, bill pop-up opening, and list rendering are triggered.

[0062] Asynchronous persistence: The Web Worker continuously receives the above sampled data and writes it to the IndexedDB circular buffer in batch transactions, retaining only the 100 records from the most recent 15 seconds.

[0063] Abnormal crash: After an agent clicks on the historical bill pop-up, the page triggers a memory overflow due to the large amount of bill data not being paginated and rendered. The browser process suddenly terminates, causing the main thread and background worker to die simultaneously, making it impossible to execute the online reporting logic.

[0064] Restart determination: After the agent refreshes the page, the initialization logic detects that the previous session was not marked as closed and the last heartbeat time is outside the threshold, thus determining that the previous session crashed abnormally.

[0065] Black box retrieval: The system automatically extracts the continuous state sequence of the 15 seconds before the crash of the previous session from IndexedDB, and uploads it along with metadata such as browser version and build version.

[0066] Precise identification: After reviewing the source package in the background, the R&D personnel discovered that the OPEN_BILL_MODAL action was recorded 3 seconds before the crash. The state snapshot 2 seconds before the crash showed that billList was filled with a huge amount of unpaginated data at once, and the memory trend indicator rose rapidly. The recording then stopped. This allowed them to directly identify the unpaginated billing interface and rendering logic as the root cause.

[0067] See Figure 2 This is a schematic diagram of the architecture of the black box tracing and collection method for communication state before browser crash provided in this application. The state sampling probe in the main thread samples the state changes of business state and the key signaling / events of WebSocket / WebRTC core, and delivers them to the background asynchronously through postMessage. The off-screen thread Web Worker in the background stores the received sampled data into the memory buffer queue, performs throttling batch processing, and writes the transaction to the local persistence layer IndexedDB through the ring overlay control logic.

[0068] See Figure 3The following is a sequence diagram for crash detection, source tracing, and recovery. When an agent operates the communication workbench normally, the main thread continuously sends status snapshots and signaling logs to the off-screen black box. The off-screen black box writes (Session S1, active) to the local IndexedDB via high-frequency circular overwrite. When an agent triggers a complex operation leading to a memory leak and attempts to refresh or reopen the page, the main thread initializes and checks the historical Session status. If it finds that S1 is still active and the heartbeat is interrupted, it determines that S1 has crashed abnormally. It extracts the last 10 seconds of circular buffer data before the S1 crash from the local IndexedDB and automatically packages and uploads it to the black box source tracing file. After completion, it cleans up the S1 data and starts a new Session S2.

[0069] Compared to existing technologies, this application differs in the following ways: The crash recovery paradigm adopts "local retention first, and retrieval on the next startup": Existing front-end monitoring mostly relies on immediately initiating network reporting at the time of a crash. This application solves the fundamental blind spot of not being able to report online when the browser process dies by using local circular persistence and automatic retrieval after restart.

[0070] Combining a circular buffer with background thread writing for browser runtime black box: Compared to common local log accumulation or main thread synchronous storage, this application achieves low-overhead, constant space retention of recent window data through a combination of Web Worker + IndexedDB / OPFS + fixed slot overlay.

[0071] Establish a crash detection mechanism based on session state machine and heartbeat interruption: Existing solutions often can only detect "page has been left", and it is difficult to distinguish between normal closure and abnormal crash; this invention improves the accuracy of abnormal exit identification by determining the active / closed state and time threshold.

[0072] Supports recovery of continuous state before crash by logical sequence: Even if the underlying data is persisted in a circular overlay manner, this application still recovers the continuous tail state sequence by logically writing sequence numbers or timestamps, avoiding the order disorder caused by simple slot scanning.

[0073] The application encapsulates communication service context and system metadata into a traceability package: This application not only saves error text, but also simultaneously retains signaling fragments, status snapshots, resource usage trends and browser environment information, making troubleshooting evidence closer to the real crime scene.

[0074] This application has the following beneficial effects: Breaking through the monitoring blind spot of browser process-level crashes: This application does not rely on network reporting immediately after a crash, but instead continuously persists the data of the most recent window before the crash to the local machine, so that the crash context can be recovered and retrieved after the next page launch.

[0075] Maintain low load on the main thread: By using sampling probes, asynchronous message passing, background batch disk flushing, and fixed-length ring overlay mechanism, high-frequency serialization and I / O are separated from the main thread, reducing interference with page rendering and communication services.

[0076] Improve troubleshooting accuracy in complex communication scenarios: Black box data simultaneously retains timestamps, key signaling, status snapshots, and memory trend clues, enabling developers to reconstruct the business state flow in the last few seconds before the crash, instead of relying solely on user verbal descriptions.

[0077] Controlling storage usage and reporting volume: Fixed slot ring coverage is adopted, and old data is automatically eliminated to avoid the local log from growing indefinitely; during crash recovery, only data within a specified window is extracted and compressed for uploading, reducing local storage pressure and network costs.

[0078] Local persistence implementation compatible with multiple browsers: While maintaining consistency in the overall mechanism, IndexedDB or OPFS can be preferred to balance general compatibility and high-performance scenarios.

[0079] The high-performance implementation based on OPFS mentioned above refers to the ability of background workers to use synchronized file handles to achieve more frequent sequential writes in a browser environment that supports Origin Private FileSystem, thereby reducing IndexedDB transaction overhead and supporting millisecond-level sampling requirements.

[0080] Alternatively, this application embodiment can choose to combine a watchdog implementation with Service Worker: the page can periodically send heartbeats to Service Worker; when the latter detects that the heartbeat is interrupted and has not received a normal shutdown signal, it can directly pull the black box data in the background and trigger the upload without waiting for the user to reopen the page.

[0081] This application can also integrate a visual playback implementation of DOM (Document Object Model) change recording: It can write the summary of DOM incremental changes, virtual list positions or component hierarchy changes in the last few seconds before the crash into a circular buffer, so that developers can not only view the status data, but also reconstruct the near-video-like interface trajectory before the crash.

[0082] This application can also choose to implement a tiered sampling method based on data value: real-time triggering sampling is used for high-value events such as SIP signaling, agent status, and alarm events, while periodic sampling is used for global status snapshots and memory metrics, thereby further controlling write costs while maintaining traceability capabilities.

[0083] Secondly, embodiments of this application provide a device for tracing and collecting the black box of a browser's communication state before a crash, the device comprising: The initialization module generates a brand new page session ID each time the page loads and marks the page's session state as active; during page operation, it periodically refreshes the page session's most recent heartbeat time. The sampling module is used to sample the status of the communication workbench and asynchronously deliver the sampled data to the background thread. The sampled data includes a lightweight global status snapshot of the communication workbench, key signaling logs, key user actions, and memory trend indicators. The background thread is used to store the sampled data in a circular buffer. The session state update module is used to mark the session state of the page as closed when the page triggers the normal closing process; The determination module is used to read the status and last heartbeat time of the previous session on the page from the local persistent storage module when the page is reloaded. If the status of the previous session is active and the last heartbeat time has expired, it is determined that the previous session was abnormal. The source tracing module is used to find the corresponding cached data in the circular buffer by using the previous page session ID for pages that have encountered an anomaly, and extract the tail data before the crash in chronological order to form a continuous state sequence.

[0084] In one possible implementation, the sampling module is specifically used for: The sampled data is asynchronously delivered to the memory buffer queue of the background thread, and the data to be written in the current batch is read from the memory buffer queue when the preset time interval or the queue length reaches the threshold. Calculate the monotonically increasing current global write sequence number for the current batch of data to be written, and map it to the fixed slot index of the circular buffer through modulo operation; Write the data to be written to the target slot indicated by the fixed slot index, while overwriting the historical records with smaller global write sequence numbers in the same slot.

[0085] In one possible implementation, the traceability module is specifically used for: Scan all slots in the circular buffer corresponding to the previous page session ID, sort the cached data in all slots in ascending order according to the monotonically increasing global write sequence number, and restore the sequential data that reflects the real time series. The sequential data within the preset window is acquired to form a continuous state sequence.

[0086] In one possible implementation, the device further includes a processing module for: The continuous state sequence is subjected to desensitization, metadata encapsulation, and compression, and the processing results are uploaded to the monitoring server; the metadata includes browser version, operating system, page build version, user terminal hardware feature summary, and crash determination reason; After uploading, clear the cached data corresponding to the previous page session ID or mark the data as retrieved.

[0087] In one possible implementation, the sampling module is further configured to: For at least one of the following: lightweight global state snapshot, critical signaling log, key user actions, and memory trend indicators, periodic sampling or event-triggered sampling shall be used.

[0088] In one possible implementation, the device further includes an analysis module for: Extract a lightweight global state snapshot from the processing results, obtain the agent status based on the lightweight global state snapshot, and locate the stage of the service when the crash occurred. Extract key signaling logs from the processing results, and reconstruct the interaction timing of the communication protocol based on the key signaling logs; Extract key user actions from the processing results, and determine the crash triggering action based on the user's operation path; Extract memory trend indicators from the processing results. If memory usage increases sharply before the crash, the cause of the crash is determined to be memory overflow.

[0089] In one possible implementation, the device further includes an update module for: Get the second page session ID, second session state, and second last heartbeat time of the reloaded page; Store the second page session ID, the second session state, and the second last heartbeat time in the local persistent storage module, and delete the previously stored previous page session ID, the state of the previous session on this page, and the last heartbeat time.

[0090] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned methods for tracing and collecting the black box of communication status before a browser crash.

[0091] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0092] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are described simply because they are similar to the method embodiments; relevant parts can be referred to the descriptions of the method embodiments.

[0094] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for tracing and collecting black box data on the communication state before a browser crash, characterized in that, The method includes: A brand new page session ID is generated each time the page loads, and the page session state is marked as active; during page operation, the most recent heartbeat time of the page session is periodically refreshed; The communication workbench is sampled for status, and the sampled data is asynchronously delivered to the background thread. The sampled data includes a lightweight global status snapshot of the communication workbench, key signaling logs, key user actions, and memory trend indicators. The background thread is used to store the sampled data in a circular buffer. When the page triggers the normal closing process, the page's session state is marked as closed; When the page is reloaded, the state of the previous session and the last heartbeat time on the page are read from the local persistent storage module. If the state of the previous session is active and the last heartbeat time has expired, it is determined that the previous session was abnormal. For pages that experience an anomaly, the corresponding cached data is searched in the circular buffer using the previous page session ID. The tail data before the crash is extracted in chronological order to form a continuous state sequence.

2. The method according to claim 1, characterized in that, The asynchronous delivery of sampled data to a background thread includes: The sampled data is asynchronously delivered to the memory buffer queue of the background thread, and the data to be written in the current batch is read from the memory buffer queue when the preset time interval or the queue length reaches the threshold. Calculate the monotonically increasing current global write sequence number for the current batch of data to be written, and map it to the fixed slot index of the circular buffer through modulo operation; Write the data to be written to the target slot indicated by the fixed slot index, while overwriting the historical records with smaller global write sequence numbers in the same slot.

3. The method according to claim 1, characterized in that, The process involves searching for the corresponding cached data in the circular buffer using the previous page session ID, extracting the tail data before the crash in chronological order, and forming a continuous state sequence, including: Scan all slots in the circular buffer corresponding to the previous page session ID, sort the cached data in all slots in ascending order according to the monotonically increasing global write sequence number, and restore the sequential data that reflects the real time series. The sequential data within the preset window is acquired to form a continuous state sequence.

4. The method according to claim 3, characterized in that, The method further includes: The continuous state sequence is subjected to desensitization, metadata encapsulation, and compression, and the processing results are uploaded to the monitoring server; the metadata includes browser version, operating system, page build version, user terminal hardware feature summary, and crash determination reason; After uploading, clear the cached data corresponding to the previous page session ID or mark the data as retrieved.

5. The method according to claim 1, characterized in that, The state sampling of the communication workbench includes: For at least one of the following: lightweight global state snapshot, critical signaling log, key user actions, and memory trend indicators, periodic sampling or event-triggered sampling shall be used.

6. The method according to claim 4, characterized in that, The method further includes: Extract a lightweight global state snapshot from the processing results, obtain the agent status based on the lightweight global state snapshot, and locate the stage of the service when the crash occurred. Extract key signaling logs from the processing results, and reconstruct the interaction timing of the communication protocol based on the key signaling logs; Extract key user actions from the processing results and determine the crash triggering action based on the user's operation path; Extract memory trend indicators from the processing results. If memory usage increases sharply before the crash, the cause of the crash is determined to be memory overflow.

7. The method according to claim 4, characterized in that, The method further includes: Get the second page session ID, second session state, and second last heartbeat time of the reloaded page; Store the second page session ID, the second session state, and the second last heartbeat time in the local persistent storage module, and delete the previously stored previous page session ID, the state of the previous session on this page, and the last heartbeat time.

8. A device for tracing and collecting the black box of a browser's communication state before a crash, characterized in that, The device includes: The initialization module generates a brand new page session ID each time the page loads and marks the page's session state as active; during page operation, it periodically refreshes the page session's most recent heartbeat time. The sampling module is used to sample the status of the communication workbench and asynchronously deliver the sampled data to the background thread. The sampled data includes a lightweight global status snapshot of the communication workbench, key signaling logs, key user actions, and memory trend indicators. The background thread is used to store the sampled data in a circular buffer. The session state update module is used to mark the session state of the page as closed when the page triggers the normal closing process; The determination module is used to read the status and last heartbeat time of the previous session on the page from the local persistent storage module when the page is reloaded. If the status of the previous session is active and the last heartbeat time has expired, it is determined that the previous session was abnormal. The source tracing module is used to find the corresponding cached data in the circular buffer by using the previous page session ID for pages that have encountered an anomaly, and extract the tail data before the crash in chronological order to form a continuous state sequence.

9. The apparatus according to claim 8, characterized in that, The sampling module is specifically used for: The sampled data is asynchronously delivered to the memory buffer queue of the background thread, and the data to be written in the current batch is read from the memory buffer queue when the preset time interval or the queue length reaches the threshold. Calculate the monotonically increasing current global write sequence number for the current batch of data to be written, and map it to the fixed slot index of the circular buffer through modulo operation; Write the data to be written to the target slot indicated by the fixed slot index, while overwriting the historical records with smaller global write sequence numbers in the same slot.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images