Error code positioning method and apparatus, device, and medium

Abstract

This application discloses an error code location method, apparatus, device, and medium thereof. The method includes: responding to a code error event and sending the corresponding code error information to a server; receiving source code error location information returned by the server, wherein the source code error location information is obtained by the server based on the code error information and the corresponding source code mapping file in the source code mapping file library; and visually displaying the source code error location information in a user interface. This application securely stores the source code mapping file on the server side, and the server only performs error location parsing when necessary, avoiding direct exposure of the source code mapping file in the production environment, thereby significantly improving the security and confidentiality of the source code.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an error code location method, apparatus, device, and medium thereof. Background Technology

[0002] As the complexity of modern web applications continues to increase, code debugging and error monitoring have become important technical aspects to ensure user experience and application stability. Modern front-end applications are deployed to the production environment after being compiled, compressed, and obfuscated. While this process optimizes the code's running efficiency, it also makes it difficult to directly locate error information in the source code, thus limiting the diagnosis and repair of problems.

[0003] In existing error monitoring solutions, to pinpoint the source code when errors occur in the production environment, source code mapping files are typically deployed along with the compiled code. Since source code mapping files contain complete source code content and file structure information, their exposure in the production environment poses a risk of leaking trade secrets and core algorithms if maliciously obtained. Furthermore, when an error occurs, the source code mapping file needs to be parsed on the client side. Because source code mapping files are usually large, downloading and parsing them on the client side increases network load and page load time, especially on low-performance devices, severely impacting user experience. Summary of the Invention

[0004] The primary objective of this application is to solve at least one of the above-mentioned problems by providing an error code location method, apparatus, device, or medium thereof.

[0005] To achieve the various objectives of this application, the following technical solution is adopted: An error code location method provided for one of the purposes of this application includes the following steps: In response to code error events, send the corresponding code error information to the server; The server receives source code error location information returned by the server, which is obtained by the server based on the code error information and the corresponding source code mapping file in the source code mapping file library. The source code error location information is visualized and displayed in the user interface.

[0006] An error code location device provided for one of the purposes of this application includes: The error information acquisition module is configured to respond to code error events and send the corresponding code error information to the server. The source code error location module is configured to receive source code error location information returned by the server. The source code error location information is obtained by the server based on the code error information and the corresponding source code mapping file in the source code mapping file library. The visualization module is configured to visualize the source code error location information on the user interface.

[0007] A computer device provided for one of the purposes of this application includes a central processing unit and a memory, the central processing unit being configured to invoke and run a computer program stored in the memory to perform the steps of the error code location method described in this application.

[0008] A computer-readable storage medium is provided for another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the error code location method, which, when invoked by a computer, performs the steps included in the method.

[0009] Compared with existing technologies, the advantages of this application are as follows: First, by securely storing the source code mapping file on the server side and having the server perform error location and parsing only when necessary, this application effectively avoids the direct exposure of the source code mapping file in the production environment, thereby significantly reducing the risk of leakage of trade secrets and core algorithms and enhancing security.

[0010] Secondly, by parsing the source code mapping files on the server side, the downloading and parsing of these files on the client side is avoided, significantly reducing the client's network load and page load time. This greatly improves the user experience, especially on low-performance devices. Based on this, not only is application efficiency improved, but the stability and responsiveness of the application are also ensured across various terminal devices.

[0011] In addition, by visualizing source code error location information on the user interface, developers are provided with an intuitive and clear view of error location. The visualization method enables developers to quickly understand and analyze the context of the error, thereby making it more efficient to troubleshoot and fix problems. Attached Figure Description

[0012] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart illustrating a typical embodiment of the error code location method of this application; Figure 2 This is a schematic diagram illustrating the process of uploading the source code mapping file to the server in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the process of obtaining all source code mapping files generated during the code building process in this embodiment of the application; Figure 4 This is a schematic diagram of the process for generating source code error location information in the embodiments of this application; Figure 5 This is a schematic diagram of the source code mapping file integrity verification process in an embodiment of this application; Figure 6 This is a flowchart illustrating the process of filtering code error information in an embodiment of this application; Figure 7 This application's embodiments illustrate the process of visualizing source code error location information to the client; Figure 8 This is a schematic block diagram of the error code location device of this application; Figure 9 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0013] The error code location method of this application can be programmed into a computer program product and deployed on a server to run. For example, in the exemplary application scenario of this application, it can be deployed in the build server or continuous integration (CI) system of the front-end development team. The deployment environment provides front-end developers with functions such as code building, compression, obfuscation and error monitoring. Developers can configure build tasks, select optimization strategies, etc. The deployment environment completes the compilation and optimization of code according to the developer's operation instructions and provides the developer with efficient error location services.

[0014] In a typical embodiment of this application, after the client triggers a code error event, it responds to the code error event by sending the code error information corresponding to the event to the server. The server then processes and determines the source code error location information for this error. The source code error location information is obtained by the server based on the code error information and the corresponding source code mapping file in the source code mapping file library. Finally, the source code error location information is visualized and displayed in the user interface.

[0015] The source code mapping file automatic collection, compression, uploading, and error location method proposed in this application can be widely applied to various front-end development and operation and maintenance scenarios, such as code building, deployment, and error monitoring, helping developers quickly and accurately locate errors in the production environment and improve code debugging efficiency and stability.

[0016] Please see Figure 1 The error code location method of this application, in its typical embodiment, includes the following steps: Step S5100: Respond to the code error event and send the code error information corresponding to the event to the server; Depending on the operating environment and application scenario, the way code error events are triggered varies. This can be achieved through a pre-defined error listening mechanism in the code. For example, in front-end development, JavaScript's global error handling function can be used to capture errors during script execution; in back-end development, for Java-based applications, try-catch blocks can be used to catch exceptions, while for Python-based applications, try-except statements can be used for error handling. Once a code error event is captured, detailed information about the event is collected. This information includes the error type, such as syntax errors, runtime errors, and logical errors. Each error type has its specific meaning and possible causes. For example, syntax errors are caused by code that does not conform to language specifications, such as missing semicolons or mismatched parentheses; runtime errors are caused by various dynamic factors during code execution, such as array out-of-bounds errors or null pointer references; logical errors occur when the code is syntactically correct but does not perform as expected, such as incorrect calculation results or incorrect conditional statements. In addition to the error type, it also collects specific location information of the error, including filename, line number, and column number. This information allows for quick and precise location of the problem within the code. Furthermore, it includes code version identifiers and compressed file identifiers. The code version identifier distinguishes between different versions of the code, while the compressed file identifier distinguishes between different compressed code files.

[0017] In one embodiment, after collecting all the detailed information related to the code error events, this information is encapsulated and organized to form a structured code error information data packet. This data packet is organized according to a predefined format to ensure that the server can correctly parse and process it.

[0018] Step S5200: Receive the source code error location information returned by the server. The source code error location information is obtained by the server based on the code error information and the corresponding source code mapping file in the source code mapping file library. After receiving error messages from the client, the server determines the error location based on the corresponding source code mapping file in the source code mapping file library. A source code mapping file is a special data structure that maps the location information between processed code (such as minified JavaScript code) and the original source code. For example, in front-end development, while compressed and obfuscated code may be more efficient at runtime, directly locating the error in the compressed code is ineffective if an error occurs. In this case, the source code mapping file can map the error location from the compressed code back to the precise location in the original source code, including detailed information such as filename, line number, and column number.

[0019] In one embodiment, the server-side parsing process first extracts key identifiers from the received code error information, such as code version identifiers and compressed file identifiers. These identifiers are used to quickly retrieve the source code mapping file related to the current error event from the source code mapping file library. For example, in a large software project, multiple versions of code may run simultaneously, each with its corresponding source code mapping file. Using the code version identifier, the server can accurately locate the source code mapping file corresponding to the current error event, ensuring that subsequent location operations are based on the correct mapping relationship. After determining the corresponding source code mapping file, the server uses this file to convert the error location data in the code error information. Specifically, it maps the error location (such as line number and column number) in the compressed code back to its location in the original source code. This process requires precise parsing of the mapping rules in the source code mapping file. For example, the source code mapping file contains a complex mapping table that records the mapping relationship between each character in the compressed code and its corresponding character in the original source code. By parsing this mapping table, the server can accurately convert the error location into location information in the original source code, including file path, line number, and column number.

[0020] After mapping the error location, the server further extracts contextual source code snippets related to the error location from the source code repository. This helps developers more intuitively understand the specific logic behind the error. For example, if the error occurs in a function, the server will not only return the precise location of the function but also extract several lines of code above and below it as contextual source code snippets. These snippets provide developers with sufficient information to quickly pinpoint the root cause of the problem.

[0021] After completing the above parsing and extraction operations, the server encapsulates the generated source code error location information into a structured data packet. This packet contains the specific location of the error (file path, line number, column number), contextual source code snippets, and possible error cause analysis, and then sends the data packet back to the client over the network. During network transmission, the server employs encrypted transmission mechanisms, such as HTTPS, to ensure security, and also compresses the data packet to reduce transmission latency and improve transmission efficiency.

[0022] Step S5300: Visualize the source code error location information in the user interface.

[0023] After receiving the source code error location information returned by the server, the client can convert the data into a format suitable for front-end display. For example, information such as file paths and line numbers can be converted into hyperlinks, which can directly jump to the corresponding code location in the code editor when clicked. The context source code snippets will be formatted into code blocks with syntax highlighting so that developers can quickly identify the code structure and potential problems.

[0024] In terms of user interface design, a specific error display area is created and placed in a prominent position in the development tool or monitoring platform. In one embodiment, this area displays error information in a hierarchical structure. The top displays an overview of the error, including the error type, occurrence time, and severity. Below this, a code snippet display area is set up, highlighting the line of code containing the error, along with contextual code snippets. Different colors and font styles can be used to distinguish different syntax elements, such as keywords, variables, and comments, to enhance readability.

[0025] In some embodiments, dynamic interactive features can be provided. For example, developers can hover the mouse over a line of code in a code snippet to view detailed information about that line, such as variable values ​​and call stack information. Furthermore, search and filtering functions can be provided, allowing developers to quickly find specific error messages based on criteria such as error type, filename, and code snippet.

[0026] From the above description of the typical embodiments of this application, it can be understood that this application has many advantages, including but not limited to the following aspects: First, by securely storing the source code mapping file on the server side and having the server perform error location and parsing only when necessary, this application effectively avoids the direct exposure of the source code mapping file in the production environment, thereby significantly reducing the risk of leakage of trade secrets and core algorithms and enhancing security.

[0027] Secondly, by parsing the source code mapping files on the server side, the downloading and parsing of these files on the client side is avoided, significantly reducing the client's network load and page load time. This greatly improves the user experience, especially on low-performance devices. Based on this, not only is application efficiency improved, but the stability and responsiveness of the application are also ensured across various terminal devices.

[0028] In addition, by visualizing source code error location information on the user interface, developers are provided with an intuitive and clear view of error location. The visualization method enables developers to quickly understand and analyze the context of the error, thereby making it more efficient to troubleshoot and fix problems.

[0029] For further embodiments, please refer to Figure 2 Before responding to a code error event and sending the corresponding code error information to the server, the following steps are included: Step S4100: Obtain all source code mapping files generated during the code building process, perform streaming compression on the source code mapping files, and generate compressed data streams in real time; During the code building process, the source code is compiled, compressed, obfuscated, and other processes to generate deployable code. At the same time, a source map file is generated, which records the mapping relationship between the built code and the original source code.

[0030] This step requires retrieving all source code mapping files generated during the code build process as soon as the build is complete. In one embodiment, this is achieved through the hook mechanism of the build tool. For example, in a front-end project using build tools such as Webpack, a plugin or hook can be configured to trigger automatically upon completion of the build, automatically collecting the generated source code mapping files. These source code mapping files can be stored in a specific location within the build output directory. At this point, based on predefined file naming rules and paths, the complete paths of all source code mapping files can be retrieved by traversing the output directory and its subdirectories.

[0031] After obtaining the source code mapping file, it is compressed. Since the source code mapping file contains a large amount of data, direct storage and transmission would consume significant storage space and network bandwidth. Therefore, streaming compression technology can be used for transmission. Streaming compression technology allows compression to be performed while the file is being read, eliminating the need to load the entire file into memory, thus saving memory resources and improving processing efficiency. For example, compression algorithms such as Gzip can be used. By creating a compression stream, the source code mapping file is read and compressed block by block. During compression, the compressed data stream is generated in real time, indicating that the compression operation is continuous and will not cause processing delays due to large file sizes.

[0032] Step S4200: Asynchronously upload the compressed data stream to the server, and simultaneously upload the corresponding code version identifier, compressed file identifier and integrity verification code, and store them in the source code mapping file library. Asynchronous uploads can be implemented using modern programming frameworks and network communication technologies. For example, in a front-end environment, JavaScript's XMLHttpRequest or Fetch API can be used in conjunction with Promise or async / await syntax to achieve asynchronous operations; in a back-end environment, such as using Node.js, its non-blocking I / O features can be leveraged to send compressed data streams via the http module or third-party libraries (such as axios). The asynchronous mechanism ensures that the main thread is not blocked during the upload process, thereby improving response speed and user experience.

[0033] In one embodiment, during the upload process, the compressed data stream is divided into multiple chunks and sent to the server one chunk at a time. This chunked upload method not only improves upload reliability but also supports resuming interrupted uploads in case of network problems. For example, if the network connection is interrupted, successfully uploaded chunks can be recorded, and the upload can resume from the point of interruption once the network is restored, without having to restart the entire file upload process. Each data chunk is timestamped and assigned a sequence number before being sent, so that the server can correctly reassemble these data chunks.

[0034] Metadata such as code version identifier, compressed file identifier, and integrity checksum will also be sent along with the compressed data stream. The code version identifier (such as Git's commit ID or version number) is used to identify the code version corresponding to the source code mapping file; the compressed file identifier (such as UUID) is used to uniquely identify each compressed source code mapping file, ensuring that different files can be accurately distinguished and managed on the server side; the integrity checksum (such as SHA-256 hash value) is used to verify whether the file remains intact during transmission, preventing data corruption or tampering.

[0035] The server processes uploaded compressed data streams through a dedicated receiving interface. Upon receiving data blocks, the server reassembles these blocks sequentially based on their sequence numbers and timestamps to restore the complete compressed file. Simultaneously, the server verifies the received integrity checksum by recalculating the hash value of the received data and comparing it with the checksum uploaded to ensure file integrity and consistency. After successful verification, the server associates and stores the compressed source code mapping file and related metadata in the source code mapping file repository. The source code mapping file repository is a structured storage system, such as a relational database or NoSQL database, used to store file metadata information. It is combined with object storage services (such as AWS S3 or Alibaba Cloud OSS) to store the actual compressed files. For example, metadata information (including code version identifiers, compressed file identifiers, integrity checksums, etc.) is stored in the database, while the compressed files are stored in the object storage service and indexed by unique identifiers.

[0036] Step S4300: In response to the file successfully stored event, delete the corresponding source code mapping file locally.

[0037] Once the server completes the storage operation of the source code mapping file, it sends a confirmation message to the client, indicating that the source code mapping file has been successfully stored in the source code mapping file repository. Upon receiving this confirmation message, the client triggers a file successful storage event. This event is a prerequisite for deleting the local source code mapping file, ensuring that the local file deletion operation is performed only after the file is securely stored on the server. For example, in a front-end environment, this can be achieved through integration with build tools (such as Webpack) or development environments (such as VS Code) plugins. For instance, a Webpack plugin can listen for file storage events during the build process and invoke the file deletion operation when the event is triggered. In a back-end environment, such as Node.js, the built-in `fs` module can be used to manipulate the file system and delete specified source code mapping files.

[0038] In this embodiment, the source code mapping file is compressed in real time using streaming compression technology to generate a compressed data stream. This not only saves storage space and network bandwidth but also improves processing efficiency and avoids processing delays caused by large files. Then, asynchronous upload technology is used to upload the compressed data stream to the server, and a chunked upload method is used during the upload process to enhance upload reliability, support breakpoint resume, and further improve the user experience. At the same time, metadata such as code version identifier, compressed file identifier, and integrity check code are uploaded to ensure the integrity and consistency of the file during transmission, which facilitates accurate file management and verification on the server side. Finally, in response to the file successfully stored event, the local source code mapping file is deleted, freeing up local storage space and avoiding the security risks that may arise from exposing the source code mapping file in the local environment.

[0039] For further embodiments, please refer to Figure 3 To obtain all source code mapping files generated during the code build process, the following steps are involved: Step S4110: Monitor the completion status of code building. When the completion status indicates that the code building process has been completed, traverse the corresponding output directories to match and obtain all source code mapping files according to the predefined file naming rules. Code building can be accomplished by specialized build tools (such as Webpack, Maven, Gradle, etc.). These tools generate various status information during the build process, such as build progress, success or failure flags, etc. You can determine whether the build is complete by listening to these tools' events or checking their generated log files. For example, in a front-end project, Webpack will trigger a specific event upon completion of the build; you can register a listener for this event to receive the notification. In back-end projects, such as Java projects using Maven, you can monitor Maven's log output; when a flag such as "BUILD SUCCESS" is detected, you can confirm that the build is complete.

[0040] Once the code build process is complete, the source code mapping file retrieval operation begins. Source code mapping files are generated during the build process and stored in the output directory according to certain naming rules. These naming rules can be based on project configuration, default settings of the build tool, or conventions established by the development team. For example, source code mapping files can have the .map extension, and the filename can include a build timestamp, module name, or other identifiers. In this case, these naming rules need to be predefined to accurately identify and match source code mapping files.

[0041] Based on these predefined file naming rules, the code traverses to construct the output directory and its subdirectories. This process can be achieved through file system operations. For example, in a Node.js environment, the `readdir` and `readdirSync` methods of the `fs` module can be used to read directory contents, combined with regular expressions to match filenames. In front-end projects using the Webpack build tool, the output directory path can be obtained after the build is complete through Webpack's plugin mechanism. Then, file searches can be performed, checking each file in the output directory one by one, and using regular expressions and other matching methods to filter out files that conform to the source code mapping file naming rules.

[0042] Step S4120: Based on preset filtering rules, filter invalid mapping files in the source code mapping files whose file type is characterized as debugging type or temporary type; During the code build process, in addition to generating source code mapping files for the production environment, some debugging mapping files or temporary files are also generated. These files are used in the development and testing phases to help developers quickly locate problems, but they are not suitable for error location and management in the production environment. For example, debug-type source code mapping files contain additional debugging information, while temporary files are merely intermediate artifacts in the build process. If these files are mistakenly uploaded to the server, they will not only occupy additional storage space but may also cause confusion in error location.

[0043] A predefined set of filtering rules distinguishes between debug and temporary files based on their extensions, specific identifiers in the filename, file size, or other metadata. For example, debug files might have the extension .debug.map, while temporary files might be named with prefixes like temp_ or tmp_. According to these filtering rules, each obtained source code mapping file is checked to determine whether it belongs to the debug or temporary type. If a file meets the characteristics of an invalid type defined in the filtering rules, it is filtered out.

[0044] Step S4130: Generate an integrity check code for the filtered and retained source code mapping files. This code is used to subsequently associate the corresponding source code mapping files with the server, allowing the server to perform integrity checks on the received source code mapping files.

[0045] Commonly used hash algorithms include MD5, SHA-1, and SHA-256. These algorithms can convert input data of arbitrary length into fixed-length hash values ​​and have high collision resistance. For example, the SHA-256 algorithm converts input data into a 256-bit hash value, represented by 64 hexadecimal characters. The contents of the filtered and retained source code mapping files are read one by one and passed to the hash algorithm to generate unique hash values ​​for different source code mapping files.

[0046] The generated hash value will be uploaded to the server along with the corresponding source code mapping file as an integrity check code. The server will recalculate the hash value of the received source code mapping file using the same hash algorithm and compare it with the integrity check code provided during upload. If they match, it indicates that the file has not been tampered with or damaged during transmission; if they do not match, it indicates that the file may have encountered an error during transmission, and the server will reject the file and notify the client to re-upload it.

[0047] In this embodiment, by monitoring the completion status of code building, all source code mapping files can be obtained in a timely and accurate manner, avoiding error location problems caused by missing files. Furthermore, invalid mapping files of debug and temporary types are filtered out based on preset filtering rules, saving storage space and preventing invalid files from interfering with subsequent error location and management, thus ensuring the quality and usability of the source code mapping files. Finally, an integrity check code is generated for the filtered and retained source code mapping files, providing security for file uploads to the server and ensuring the integrity and consistency of the files during transmission.

[0048] For further embodiments, please refer to Figure 4 The server parses the source code error location information based on the code error information and the corresponding source code mapping file in the source code mapping file library, including the following steps: Step S5210: Parse the code error information and extract the code version identifier and compressed file identifier carried therein; When the client captures an error event during code execution, it generates a data packet containing detailed error information. The generated data packet includes key information such as the error type, error message, stack trace, file name of the file where the error occurred, line number, and column number. In addition, the data packet also includes code version identifiers and compressed file identifiers to support error location. These identifiers are generated during the code build process and embedded in the code error information so that the corresponding source code mapping file can be quickly located when an error occurs.

[0049] Code version identifiers are used to distinguish different versions of code. In modern software development, code undergoes multiple iterations and updates, with each update introducing new features or fixing known issues. Accurate code version identifiers are crucial for pinpointing the code's state at the time an error occurred. A code version identifier can be a simple version number (e.g., v1.0.0) or a more complex identifier, such as a Git commit hash or build timestamp.

[0050] The compression file identifier is used to distinguish different compressed code files. In front-end development, code is often compressed and obfuscated to reduce file size and improve loading speed. Each compressed file generates a corresponding source code mapping file, and the compression file identifier is used to associate the compressed code file with the source code mapping file. The compression file identifier can be a filename, a path, or a specific hash value. For example, a compressed JavaScript file might be named bundle.min.js, and its corresponding compression file identifier could be the filename itself or a hash value of the file content.

[0051] After receiving a code error message from the client, the server first parses the received data. This parsing process includes decoding the data packet format and extracting various fields. For example, if the code error message is sent in JSON format, the server uses a JSON parser to convert the data packet into an operable object. During parsing, the server extracts the code version identifier and compressed file identifier for subsequent source code mapping file retrieval.

[0052] Step S5220: Retrieve the corresponding source code mapping file from the source code mapping file library based on the code version identifier and the compressed file identifier; A source code mapping file repository is a system for storing and managing source code mapping files. It contains a large number of mapping files, each corresponding to a different version of the code and a different compressed file. In one embodiment, the source code mapping file repository builds indexes based on the file's metadata information, such as code version identifiers, compressed file identifiers, and file paths. For example, a relational database or a NoSQL database can be used to store the file metadata and to quickly query it using the index.

[0053] Once the code version identifier and compressed file identifier are extracted, their validity is first verified to ensure that the identifiers are formatted correctly and as expected. For example, the code version identifier is a Git Commit ID, which is a 40-character hexadecimal string. Validation tools such as regular expressions are used to check if the identifier conforms to this format. If the identifier is invalid, an error message is logged and the user or developer is notified, prompting them to check the accuracy of the error message. After verifying the identifier's validity, a query request is constructed, using the code version identifier and compressed file identifier as query parameters to retrieve the corresponding source code mapping file from the source code mapping file repository.

[0054] Step S5230: Based on the source code mapping file, map the error location data in the code error information to the file path, line number, and column number corresponding to the original source code; A source map is a special data structure that records in detail the mapping relationship between the built code and the original source code. This mapping relationship can be represented in JSON format and contains multiple fields, such as version number, file name, list of source files, and mapping information. The mappings field is a string containing complex encoding information used to describe the positional mapping between the compressed code and the original code.

[0055] Upon receiving the source code mapping file, the first step is to parse its contents. For example, a JSON parsing tool might load the contents of the source code mapping file into memory, converting it into a workable data structure. This parsed data structure will contain all the necessary mapping information, enabling accurate mapping based on the error location data.

[0056] Error location data in code error messages includes filename, line number, and column number. This information is captured during code runtime, but the error location data points to the processed code location. At this point, it is necessary to convert this error location information to the location in the original source code.

[0057] In one embodiment, the `mappings` field in the source code mapping file uses a string based on Base64 VLQ (Variable Length Quantity) encoding to represent the mapping relationship. This encoding method can efficiently store a large amount of mapping information. When parsing the `mappings` field, a specific decoding algorithm is used to convert it into readable mapping data. For example, a mapping data is represented as an array, where each element contains the filename, line number, and column number of the original source code, as well as the line number and column number of the compressed code. By parsing the `mappings` field, a mapping table is constructed, which maps each position in the compressed code to a position in the original source code. When erroneous position data is received, the mapping entry matching the erroneous position is retrieved from the mapping table. For example, based on the line number and column number of the compressed code, the corresponding original source code filename, line number, and column number in the mapping table are looked up.

[0058] After finding the corresponding mapping entry, the file path, line number, and column number of the original source code are extracted, associated with the code error information, and encapsulated into a new data object for developers or subsequent error handling processes. Based on this, developers can directly locate errors in the original source code instead of looking for problems in the processed code, thereby greatly improving debugging efficiency and accuracy.

[0059] Step S5240: Based on the code version identifier, file path, line number, and column number, extract the context source code fragment corresponding to the preset number of lines from the source code repository, and generate source code error location information containing the code version identifier, file path, line number, column number, and the context source code fragment.

[0060] A source code repository is a system that stores all versions of a project's code, managed using a version control system (such as Git). Interacting with the repository allows you to extract corresponding contextual source code snippets. For example, with a Git repository, you can access a specific version of the code via the Git command-line tool or the Git API. By identifying the code version, you can precisely pinpoint the code state at the time of the error. Before extracting the contextual source code snippets, you need to determine the extraction range, i.e., the preset number of lines. This range can be configured according to actual needs. For example, extracting five lines of code before and after the error line as context provides sufficient information to help developers understand the specific logic and surrounding code structure of the error. Specifically, locate the specific source file based on the file path, determine the exact location of the error based on the line and column numbers, and extract the corresponding code snippets from the file content based on the error line number and the preset context range. For example, if the error occurs on line 42, and the preset context range is five lines before and after, then lines 37 to 47 will be extracted as the context snippets.

[0061] After extraction, the code version identifier, file path, line number, column number, and contextual source code fragments are integrated into a structured source code error location information, which can then be directly displayed to developers via API or user interface.

[0062] In this embodiment, by parsing the code error information to extract key identifiers, the corresponding source code mapping file can be quickly retrieved from the source code mapping file library. Then, the error location data is accurately mapped to the file path, line number, and column number of the original source code. Finally, the context source code fragment is extracted from the source code repository to generate complete source code error location information. Based on this, not only can errors be quickly located, but also rich context information can be provided to help developers quickly understand the specific logic of the error, thereby greatly improving debugging efficiency and accuracy.

[0063] For further embodiments, please refer to Figure 5 Before associating the storage with the source code mapping file library, the following steps are included: Step S6100: Receive the integrity check code verification result returned by the server. The check code result is generated by the server calculating a new check code from the received compressed data stream and comparing the new check code with the corresponding integrity check code. When a client uploads a compressed data stream to the server, it simultaneously sends a pre-calculated integrity checksum (such as a SHA-256 hash value). As the server receives the compressed data stream, it calculates the hash value of the received data in real time and generates a new checksum. This process occurs after data reception is complete to ensure the accuracy of the checksum. For example, the server can use a built-in hash algorithm library (such as hashlib in Python or the crypto module in Node.js) to calculate the new checksum.

[0064] The server's calculation of the new checksum is transparent, requiring no client intervention. The client only needs to ensure that the uploaded compressed data stream is complete and error-free, and that no network interruption or other abnormalities occurred during the upload process. After calculating the new checksum, the server compares it with the integrity checksum provided by the client during upload. This comparison process is automated. The server checks whether the two checksums are completely identical. If they are identical, it indicates that the uploaded compressed data stream has maintained its integrity during transmission; if they are inconsistent, it indicates that the data may have been tampered with or corrupted during transmission.

[0065] The server generates a verification result based on the comparison results and returns it to the client. The verification result can be a simple status code or message indicating whether the verification passed or failed. For example, if the verification passes, the server returns a status code 200 OK with a message "Verification passed, file intact"; if the verification fails, it returns an error status code (such as 400 Bad Request) with an error message "Verification failed, file corrupted or tampered with".

[0066] Step S6200: When the verification result indicates that the verification failed, a re-upload request is sent to the server to trigger the corresponding source code mapping file re-upload process.

[0067] In one embodiment, when the client receives a verification failure result from the server, it first records detailed error information, including the time the error occurred, the file identifier, and the specific details of the checksum mismatch. By recording the error information, the root cause of the problem can be quickly located, and corresponding measures can be taken.

[0068] After recording the error information, a pre-defined strategy is used to determine whether to trigger a re-upload process. In some embodiments, if the verification failure is due to network problems or temporary transmission errors, the file is automatically re-uploaded. The re-upload request includes necessary metadata information, such as file path, file name, and code version identifier, so that the server can correctly process the re-uploaded file.

[0069] Sending a re-upload request can be done in several ways. For example, in an HTTP-based system, the client can use a POST or PUT request to send a re-upload instruction to the server. The request body contains the file's metadata information and a clear identifier that indicates the request is a re-upload request.

[0070] Upon receiving a re-upload request, the server performs a series of operations to process it. First, the server reads the metadata information in the request, confirms the uniqueness of the file, and locates the corresponding storage location based on the file path and code version identifier. If the server detects that the file already exists, it determines whether to overwrite the original file according to a preset policy.

[0071] If the re-upload still fails, a preset strategy will determine whether to trigger the re-upload process again. A maximum number of retries can be set, such as 3. If the file upload still fails after reaching the maximum number of retries, detailed failure information will be recorded, and the user or system administrator will be notified for manual intervention. For example, an email or instant message may be sent to inform the user of the specific details of the file upload failure and suggest that the user check their network connection or contact technical support.

[0072] In this embodiment, by sending a pre-calculated integrity check code when the client uploads the compressed data stream, and the server calculating a new check code in real time after receiving the compressed data stream and comparing it with the new check code, the integrity of the data during transmission can be accurately determined. When the check fails, the client automatically triggers the re-upload process according to the preset strategy, and after multiple failed retries, relevant personnel are notified in a timely manner to perform manual intervention. This improves the reliability and accuracy of data transmission and effectively reduces the risk of errors caused by data corruption or tampering.

[0073] For further embodiments, please refer to Figure 6 Before sending the code error information corresponding to the event to the server, the following steps are included: Step S3100: Perform pre-filtering processing on the code error information based on a pre-configured filtering rule set, wherein the filtering rule set includes error type matching rules, access path criticality judgment rules, and duplicate error suppression rules. When code error events are triggered and code error messages are generated during code execution, these error messages contain various types of errors, such as syntax errors, runtime errors, and network errors. Some errors may be caused by temporary network problems or user operations. These errors do not need to be reported to the server for further processing. That is, before sending the code error messages to the server, these error messages need to be pre-filtered.

[0074] The pre-configured filtering rule set contains multiple rules used to determine whether code error messages meet the reporting criteria. These filtering rules mainly include error type matching rules, access path criticality judgment rules, and duplicate error suppression rules.

[0075] Error type matching rules are used to determine whether an error type falls within the scope of errors that need to be reported. For example, some error types are considered low priority or irrelevant to system stability and can be filtered out. Error type matching rules can be implemented by examining the error type field in the error message. For example, if the error type is "404 Not Found" and the system is configured to ignore this type of error, then the error message will be filtered out.

[0076] Access path criticality judgment rules are used to assess whether the access path at the time of the error falls within the scope of reporting. Some access paths may correspond to the core functions of the application, while others may only be auxiliary functions or user exploratory operations. By analyzing the access path at the time of the error, it can be determined whether the error should be reported. For example, if the error occurs on the user login page (a critical path), the code error message will be retained and reported; however, if the error occurs on a non-critical page accessed by the user, the code error message will be filtered out.

[0077] Duplicate error suppression rules are used to identify and filter repetitive error messages. An error may occur multiple times in a short period of time; for example, a failed network request can lead to multiple identical error reports. To prevent the server from being overwhelmed by a large number of repetitive code error messages, reported code error messages are logged, and identical errors are ignored for a preset time period.

[0078] During the pre-filtering process, each code error message is examined one by one, applying each rule from the aforementioned rule set. This process can be implemented using conditional statements and logical operators in a programming language. For example, it can first check if the error type is in the allowed reporting list; if not, the code error message is directly filtered out. If the error type matches, it further checks if the access path belongs to a critical path, and finally checks if the error is a duplicate; if so, reporting is suppressed.

[0079] This multi-layered filtering mechanism effectively reduces the number of error messages reported to the server while ensuring that the reported information is relevant and important.

[0080] Step S3200: When the code error information does not meet any of the error type matching rules, the access path criticality judgment rules, and the duplicate error suppression rules, the sending of the code error information to the server is stopped.

[0081] When code error messages undergo pre-filtering, each message is checked against error type matching rules, access path criticality judgment rules, and duplicate error suppression rules. If a code error message does not meet any of these rules, it is determined to be a non-critical or duplicate error, and measures are taken to stop its transmission to the server.

[0082] In this embodiment, by pre-filtering code error information based on a pre-configured set of filtering rules, error information that meets the reporting criteria can be accurately selected. This multi-layered filtering mechanism not only effectively reduces the number of error messages reported to the server, preventing the server from being overwhelmed by a large number of irrelevant errors, but also ensures that the reported information is relevant and important, improving the efficiency and accuracy of error processing on the server side. Furthermore, if a code error message does not meet any rule, the transmission of that information to the server is stopped, further optimizing the code error reporting process and avoiding unnecessary resource waste.

[0083] For further embodiments, please refer to Figure 7 The source code error location information is visualized and displayed on the user interface, including the following steps: Step S5310: Based on the user session identifier corresponding to the source code error location information and the preset time window, construct a target error cluster from multiple related source code error location information; A user session identifier is a unique identifier used to distinguish the interaction processes of different users. For example, in a web application, a user session identifier is a session ID that is generated when a user logs in and remains unchanged throughout the user's interaction. The user session identifier allows tracking of the user's behavioral path within the application, including triggered errors. When source code error location information is generated, this information is associated with the corresponding user session identifier. A preset time window defines the time frame within which errors are considered associated. For example, a 5-minute time window can be set, indicating that multiple errors occurring within the same user session within 5 minutes will be considered a target error cluster. The time window setting can be adjusted according to the actual application scenario to ensure the rationality and effectiveness of the target error cluster.

[0084] To construct the target error cluster, source code error location information that occurs under the same user session identifier and within a preset time window is first collected. This process can be achieved by retrieving error logs from a database or in memory. The collected source code error location information is then used to construct the target error cluster.

[0085] Step S5320: Based on the error timestamp corresponding to the source code error location information, determine the first source code error location information of the target error cluster as the main source code error information, and display the context source code fragment corresponding to the main source code error information on the first display page of the user interface; Each target error cluster contains multiple source code error location information entries. These entries are ordered by error timestamps, which record the specific time each error occurred. By analyzing the error timestamps associated with the source code error location information, the first source code error location entry in the target error cluster can be determined. The first source code error location entry refers to the earliest error that occurred in the time series, and it may be the root cause that triggered a series of subsequent errors.

[0086] Specifically, the process iterates through all source code error location information in the target error cluster, comparing the corresponding associated error timestamps. An error timestamp is a time value, in milliseconds, representing the specific moment the error occurred. The source code error location information with the smallest error timestamp is identified and marked as the primary source code error information. After determining the primary source code error information, the corresponding contextual source code fragment is extracted. The first display page visualizes this contextual source code fragment in an easy-to-read format for presentation to the user.

[0087] In some embodiments, the user interface not only displays contextual source code snippets but also shows other related information from the source code error location information on the first display page. For example, the user interface creates multiple areas, such as an error overview area to display basic error information, such as error type, error message, and error timestamp; a code display area to highlight the specific line of code where the error occurred and display the contextual source code snippet. For example, the line of code where the error occurred is displayed with a red background, while the contextual source code snippet is displayed as plain text; and navigation tools to provide toolbars or buttons that allow users to switch between different source code error location information within the target error cluster or jump to the specific code location where the error occurred.

[0088] Step S5330: Obtain all source code error location information in each target error cluster except for the main source code error information, and display the corresponding context source code fragment in a collapsible state on a second display page associated with the first display page.

[0089] After identifying and displaying the main source code error information on the first display page, further processing is performed on other error information within the target error cluster. Specifically, all source code error location information, excluding the main source code error information, is first extracted from the target error cluster. This process involves traversing the error list within the target error cluster and excluding source code error location information already marked as a main error. For each extracted source code error location information, its corresponding contextual source code fragment is obtained and set into a collapsible display format for presentation on the second display page.

[0090] The collapsible display is a user interface design pattern that allows users to expand or collapse detailed information as needed. This design effectively saves screen space while providing rich information. The second display page is linked to the first display page and can be implemented through navigation links or tabs. Users can view the main source code error information on the first display page and switch to the second display page by clicking a link or tab to view other error information related to the main error.

[0091] In this embodiment, by constructing a target error cluster based on the user session identifier and a preset time window, multiple related source code error location information can be integrated together. Then, the main source code error information is determined based on the error timestamp, and its corresponding context source code fragment is displayed on the first display page of the user interface to highlight key error information, enabling users to quickly understand the core of the problem. Furthermore, the context source code fragments of other source code error location information in the target error cluster are displayed in a collapsible state on the second display page, which saves screen space and provides rich detailed information, making it convenient for users to explore the full picture of the problem.

[0092] Please see Figure 8 This invention provides an error code location device to meet one of the purposes of this application. It is a functional embodiment of the error code location method of this application. The device includes: an error information acquisition module 5100, a source code error location module 5200, and a visualization display module 5300. The error information acquisition module 5100 is configured to respond to a code error event and send the corresponding code error information to a server. The source code error location module 5200 is configured to receive the source code error location information returned by the server, which is obtained by the server parsing the code error information and the corresponding source code mapping file in the source code mapping file library. The visualization display module 5300 is configured to visually display the source code error location information in a user interface.

[0093] In a further embodiment, the error information acquisition module 5100 includes: a data stream generation unit, configured to acquire all source code mapping files generated during the code building process, perform streaming compression on the source code mapping files, and generate a compressed data stream in real time; a data stream uploading unit, configured to asynchronously upload the compressed data stream to the server, and simultaneously upload the corresponding code version identifier, compressed file identifier, and integrity check code, and associate them with the storage in the source code mapping file library; and a file deletion unit, configured to delete the corresponding local source code mapping file in response to a file successful storage event.

[0094] In a further embodiment, the data stream generation unit includes: a directory traversal unit, configured to monitor the completion status of code building, and when the completion status indicates that the code building process has been completed, traversing the corresponding output directories to match and obtain all source code mapping files according to predefined file naming rules; a file filtering unit, configured to filter invalid mapping files in the source code mapping files whose file type is characterized as debug or temporary based on preset filtering rules; and a verification code generation unit, configured to generate integrity verification codes for the filtered and retained source code mapping files, which are then associated with the corresponding source code mapping files and uploaded to the server for the server to perform integrity verification on the received source code mapping files.

[0095] In a further embodiment, the source code error location module 5200 includes: an identifier extraction unit, configured to parse the code error information and extract the code version identifier and compressed file identifier carried therein; a file retrieval unit, configured to retrieve the corresponding source code mapping file from the source code mapping file library based on the code version identifier and compressed file identifier; an information mapping unit, configured to map the error location data in the code error information to the file path, line number, and column number corresponding to the original source code based on the source code mapping file; and a location information generation unit, configured to extract the context source code fragment corresponding to a preset number of lines from the source code repository based on the code version identifier, file path, line number, and column number, and generate source code error location information containing the code version identifier, file path, line number, column number, and the context source code fragment.

[0096] In a further embodiment, before the data stream upload unit is associated with the source code mapping file library, it includes: a check code comparison unit, configured to receive the integrity check code verification result returned by the server, wherein the check code result is generated by the server calculating a new check code from the received compressed data stream and comparing the new check code with the corresponding integrity check code; and a re-request unit, configured to send a re-upload request to the server when the verification result indicates that the verification has failed, so as to trigger the corresponding source code mapping file re-upload process.

[0097] In a further embodiment, before sending the code error information corresponding to the event to the server, the error information acquisition module 5100 includes: a filtering processing unit, configured to perform pre-filtering processing on the code error information based on a pre-configured filtering rule set, the filtering rule set including error type matching rules, access path criticality judgment rules, and duplicate error suppression rules; and a transmission termination unit, configured to terminate the transmission of the code error information to the server when the code error information does not satisfy any of the error type matching rules, the access path criticality judgment rules, and the duplicate error suppression rules.

[0098] In a further embodiment, the visualization module 5300 includes: an error cluster construction unit, configured to construct a target error cluster from multiple related source code error location information according to the user session identifier corresponding to the source code error location information and a preset time window; a main error determination unit, configured to determine the first source code error location information of the target error cluster as the main source code error information based on the error timestamp corresponding to the source code error location information, and display the context source code fragment corresponding to the main source code error information on the first display page of the user interface; and an information folding unit, configured to obtain all source code error location information in each target error cluster except for the main source code error information, and display the corresponding context source code fragment in a foldable state on a second display page associated with the first display page.

[0099] To address the aforementioned technical problems, embodiments of this application also provide computer equipment. For example... Figure 9 The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store control information sequences. When the computer-readable instructions are executed by the processor, they enable the processor to implement an error code localization method. The processor of the computer device provides computing and control capabilities, supporting the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, they enable the processor to execute the error code localization method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0100] In this embodiment, the processor is used to execute... Figure 8 The system defines the specific functions of each module and its submodules. The memory stores the program code and various data required to execute these modules or submodules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / submodules in the error code location device of this application. The server can call the server's program code and data to execute the functions of all submodules.

[0101] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the error code location method of any embodiment of this application.

[0102] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0103] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those disclosed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0104] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for locating error codes, characterized in that, include: In response to code error events, send the corresponding code error information to the server; The server receives source code error location information returned by the server, which is obtained by the server based on the code error information and the corresponding source code mapping file in the source code mapping file library. The source code error location information is visualized and displayed in the user interface.

2. The error code location method according to claim 1, characterized in that, Before responding to a code error event and sending the corresponding code error information to the server, the following should be included: Obtain all source code mapping files generated during the code building process, perform streaming compression on the source code mapping files, and generate compressed data streams in real time; The compressed data stream is asynchronously uploaded to the server, along with the corresponding code version identifier, compressed file identifier, and integrity verification code, and stored in the source code mapping file library. In response to a successful file storage event, delete the corresponding local source code mapping file.

3. The error code location method according to claim 2, characterized in that, Retrieve all source code mapping files generated during the code build process, including: Monitor the completion status of code building. When the completion status indicates that the code building process has been completed, traverse the corresponding output directories to match and obtain all source code mapping files according to the predefined file naming rules. Based on preset filtering rules, invalid mapping files in the source code mapping files that are characterized as debugging type or temporary type are filtered out; An integrity check code is generated for the filtered and retained source code mapping files. This code is then used to associate the corresponding source code mapping files with the server, allowing the server to perform integrity checks on the received source code mapping files.

4. The error code location method according to claim 1, characterized in that, The server parses the source code error location information based on the code error information and the corresponding source code mapping file in the source code mapping file library, including: Parse the code error information and extract the code version identifier and compressed file identifier carried within it; Based on the code version identifier and compressed file identifier, the corresponding source code mapping file is retrieved from the source code mapping file library; Based on this source code mapping file, the error location data in the code error information is mapped to the file path, line number, and column number corresponding to the original source code; Based on the code version identifier, file path, line number, and column number, a context source code fragment corresponding to a preset number of lines is extracted from the source code repository, and source code error location information containing the code version identifier, file path, line number, column number, and the context source code fragment is generated.

5. The error code location method according to claim 2, characterized in that, Before associating the storage with the source code mapping file library, the following steps are included: The server receives the integrity check code verification result, which is generated by the server calculating a new check code from the received compressed data stream and comparing the new check code with the corresponding integrity check code. When the verification result indicates that the verification failed, a re-upload request is sent to the server to trigger the corresponding source code mapping file re-upload process.

6. The error code location method according to claim 1, characterized in that, Before sending the code error information corresponding to the event to the server, the following should be included: The code error information is pre-filtered based on a pre-configured set of filtering rules, which includes error type matching rules, access path criticality judgment rules, and duplicate error suppression rules. When the code error information does not meet any of the error type matching rules, the access path criticality judgment rules, and the duplicate error suppression rules, the sending of the code error information to the server is stopped.

7. The error code location method according to claim 1, characterized in that, The source code error location information is visualized and displayed on the user interface, including: Based on the user session identifier corresponding to the source code error location information and the preset time window, multiple source code error location information that are related to each other are constructed into a target error cluster; Based on the error timestamp corresponding to the source code error location information, the first source code error location information of the target error cluster is determined to be the main source code error information, and the context source code fragment corresponding to the main source code error information is displayed on the first display page of the user interface; Obtain all source code error location information in each target error cluster except for the main source code error information, and display the corresponding context source code fragment in a collapsible state on a second display page associated with the first display page.

8. An error code location device, characterized in that, include: The error message acquisition module is configured to respond to code error events and send the corresponding code error message to the server. The source code error location module is configured to receive source code error location information returned by the server. The source code error location information is obtained by the server based on the code error information and the corresponding source code mapping file in the source code mapping file library. The visualization module is configured to visualize and display the source code error location information on the user interface.

9. A computer device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images