WO2017152079A1

WO2017152079A1 - Computer-implemented system and method for automating web application runtime error repairing

Info

Publication number: WO2017152079A1
Application number: PCT/US2017/020705
Authority: WO
Inventors: Vasyl MARTYNIUK
Original assignee: Codepinch, Llc
Priority date: 2016-03-04
Filing date: 2017-03-03
Publication date: 2017-09-08

Abstract

A system for repairing application errors typically includes a processor, a memory, and error report processing application stored in the memory. The system is typically configured for: receiving error information comprising a file identifier and a checksum of a client file related to an error from a client device; determining that the repository comprises a matching file having a file identifier that matches the file identifier of the client file; validating the matching file by calculating a checksum of the matching file, comparing the checksum of the matching file to the checksum of the client file, and determining that the checksum of the matching file matches the checksum of the client file; and identifying a solution to the error.

Description

COMPUTER-IMPLEMENTED SYSTEM AND METHOD FOR AUTOMATING WEB APPLICATION RUNTIME ERROR REPAIRING

CROSS-REFERENCE OF RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application Ser. No.

62/303,881, filed March 4, 2016, entitled "Computer-Implemented System and Method for Automating Web Application Runtime Error Repairing," the entirety of which is incorporated herein by reference.

FIELD OF THE INVENTION

[0002] The present invention embraces a server system that includes a processor, a memory, and an error report processing application stored in the memory. The system is typically configured for: receiving error information comprising a file identifier and a checksum of a client file related to an error from a client device; determining that the repository comprises a matching file having a file identifier that matches the file identifier of the client file; validating the matching file by calculating a checksum of the matching file, comparing the checksum of the matching file to the checksum of the client file, and determining that the checksum of the matching file matches the checksum of the client file; and identifying a solution to the error.

BACKGROUND

[0003] It is common for web applications to experience errors. As such, a need exists for an improved way of repairing errors.

SUMMARY

[0004] The following presents a simplified summary of the present disclosure in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key or critical elements of the invention or to delineate the scope of the invention. The following summary merely presents some concepts of the invention in a simplified form as a prelude to the more detailed description provided below. [0005] Embodiments of the present invention address the above needs and/or achieve other advantages by providing apparatuses (e.g., a system) and methods for repairing web application runtime errors automatically.

[0006] In one embodiment, the present invention is directed to a system and an associated method for repairing web application errors. The system typically includes a processor; a memory; and an error report processing application stored in the memory, executable by the processor and configured for: receiving error information from a client device, wherein the error information comprises information related to an error identified by the client device after executing a client file, wherein the error information comprises a file identifier of the client file and a checksum of the client file; determining that a repository comprises a matching file having a file identifier that matches the file identifier of the client file; validating the matching file, wherein validating the matching file comprises calculating a checksum of the matching file, comparing the checksum of the matching file to the checksum of the client file, and determining that the checksum of the matching file matches the checksum of the client file; in response to validating the matching file, identifying a solution to the error, wherein the solution comprises a patched file.

[0007] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error report processing application is configured for determining that the repository does not comprise the matching file; in response to determining that the repository does not comprise the matching file, transmitting a request for the matching file to a third party system; receiving the matching file from the third party system.

[0008] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error report processing application is configured for determining that the repository does not comprise the matching file; in response to determining that the repository does not comprise the matching file, transmitting a request for the matching file to the client device; receiving the matching file from the client device.

[0009] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the request for the matching file is transmitted to the client device in response to determining that a third party system does not have the matching file. [0010] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error report processing application is configured for: determining that a repository comprises an existing file having a file identifier that matches the file identifier of the client file; validating the existing file, wherein validating the existing file comprises calculating a checksum of the existing file, comparing the checksum of the existing file to the checksum of the client file, and determining that the checksum of the existing file does not match the checksum of the client file; in response to determining that the checksum of the existing file does not match the checksum of the client file, requesting a copy of the client file from the client device; receiving the copy of the client file from the client device; storing the copy of the client file in the repository, wherein the copy of the client file stored in the repository is the matching file.

[0011] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, determining that the repository comprises the matching file comprises determining that the copy of the client file has been stored in the repository.

[0012] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, determining that the repository comprises the matching file is performed after receiving the copy of the client file from the client device.

[0013] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error information comprises an error identifier of the error; wherein identifying the solution to the error comprises: searching a solution database for a solution record having both (i) a file identifier that matches the file identifier of the client file and (ii) an error identifier that matches the error identifier of the error; identifying a matching solution record, wherein the matching solution record is associated with the patched file.

[0014] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error identifier of the error comprises a line number of the error and an error message of the error; wherein the matching solution record has (i) a file identifier that matches the file identifier of the client file, (ii) a line number that matches the line number of the error, and (iii) an error message that literally matches the error message of the error. [0015] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error identifier of the error comprises a line number of the error and an error message of the error; wherein the matching solution record has (i) a file identifier that matches the file identifier of the client file, (ii) a line number that matches the line number of the error, and (iii) an error message that matches, with the exception of dynamic information, the error message of the error.

[0016] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, identifying a matching solution record comprises: determining that the solution database does not include a solution record having (i) a file identifier that matches the file identifier of the client file, (ii) a line number that matches the line number of the error, and (iii) an error message that literally matches the error message of the error; performing a regular expression search to determine that the error message of the matching solution record matches, with the exception of dynamic information, the error message of the error.

[0017] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, identifying the solution to the error comprises: identifying, in a strategy database, a repair algorithm for correcting the error; applying the repair algorithm to the matching file to create the patched file.

[0018] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, applying the repair algorithm to the matching file to create the patched file comprises: using static code analysis to parse source code of the matching file and convert the source code into an abstract syntax tree; identify a node of the abstract syntax tree associated with the error; applying the repair algorithm to fix the node associated with the error and create the patched file.

[0019] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error information comprises an error identifier of the error; wherein identifying the solution to the error comprises determining that a solution database does not have a matching solution record having both (i) a file identifier that matches the file identifier of the client file and (ii) an error identifier that matches the error identifier of the error; where identifying the repair algorithm for correcting the error and applying the repair algorithm to the matching file to create the patched file are performed in response to determining that the solution database does not have the matching solution record.

[0020] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, identifying the solution to the error comprises storing the patched file in the solution database.

[0021] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error report processing application is configured for notifying the client device that the solution to the error has been identified.

[0022] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the error report processing application is configured for transmitting a client error processing application to the client device.

[0023] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the client error processing application, when executed by the client device, is configured to cause the client device to capture the error information; transmit the error information to the system.

[0024] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the client error processing application, when executed by the client device, is configured to cause the client device to: capture the error information, the captured error information comprising the checksum of the client file;

subsequently, calculate a second checksum of the client file; compare the second checksum of the client file to the checksum of the client file; determine that the second checksum of the client file matches the checksum of the client file; in response to determining that the second checksum of the client file matches the checksum of the client file, add the error information to an error report and transmit the error report to the system.

[0025] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the client error processing application, when executed by the client device, is configured to cause the client device to: receive, from the system, a notification of the patched file; calculate a current checksum of the client file; compare the current checksum of the client file to the checksum of the client file; determine that the second checksum of the client file matches the checksum of the client file; in response to determining that the current checksum of the client file matches the checksum of the client file, download the patched file from the system; overwriting the client file with the patched file.

[0026] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, receiving the error information from the client device comprises receiving an error report from the client device.

[0027] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the file identifier of the client file comprises a filename of the client file.

[0028] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the file identifier of the client file comprises a filename of the client file, a module name of a module containing the client file, and a module version of the module containing the client file.

[0029] In one particular embodiment, either alone or in combination with any other particular embodiments of the first embodiment, the client file is a file of a script-based application.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Having thus described some embodiments of the present invention in general terms, reference will now be made to the accompanying drawings, where:

Figure 1 presents a server system environment, in accordance with one embodiments of the present invention;

Figure 2, presents a block diagram for a server system illustrated in Figure 1, in accordance with embodiments of the present invention;

Figure 3 presents a block diagram a client system illustrated in Figure 1, in accordance with embodiments of the present invention;

Figure 4A presents a process flow illustrating an error capture process implemented by an error processing application in the client system, in accordance with embodiments of the present invention;

Figure 4B presents a process flow illustrating error processing implemented by the server system, in accordance with embodiments of the present invention; Figure 4C presents a database solution search process flow implemented by the server system, in accordance with embodiments of the present invention;

Figure 4D presents an error repairing process flow implemented by the server system, in accordance with embodiments of the present invention;

Figure 4E presents an error patching process flow implemented by the error processing application in the client system, in accordance with embodiments of the present invention; and

Figure 4F presents a continuation of the process flow implemented by the server system in Figure 4B for obtaining a module from a third party system, in accordance with embodiments of the present invention;

Figure 4G presents a continuation of the process flow implemented by the server system in Figure 4B for obtaining a module from the client system, in accordance with embodiments of the present invention;

Figure 4H presents a continuation of the process flow implemented by the server system in Figure 4B for obtaining a file from the third party system, in accordance with embodiments of the present invention;

Figure 41 presents a continuation of the process flow implemented by the server system in Figure 4B for obtaining a file from the client system, in accordance with embodiments of the present invention;

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0031] Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all,

embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein;

rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Where possible, any terms expressed in the singular form herein are meant to also include the plural form and vice versa, unless explicitly stated otherwise. Also, as used herein, the term "a" and/or "an" shall mean "one or more," even though the phrase "one or more" is also used herein. Furthermore, when it is said herein that something is "based on" something else, it may be based on one or more other things as well. In other words, unless expressly indicated otherwise, as used herein "based on" means "based at least in part on" or "based at least partially on." Like numbers refer to like elements throughout.

[0032] In one aspect, the present invention embraces a system and a computer implemented method for repairing web application runtime errors. A module in a web

application may be upgraded, downgraded, or manually modified by a client. As such, different clients may have different variants of the same module (e.g., due to upgrades, downgrades, or manual modification). Because different clients may have different variants of the same module, it is difficult to systematically apply error fixes. For example, even if an error-repair system has corrected an error in an original version of a module, this corrected version of the module would not likely work for clients experiencing the same error, but who have modified the original version of the module. Another problem associated with error repairing is that a client may modify a module in the time between when an error is identified and when a solution to the error is identified. Although systems exist for repairing application errors, these systems do not address these problems associated with dynamically changing web applications.

[0033] However, the present invention presents an improved system to automatically repair errors encountered by multiple clients considering the dynamic nature of web applications. The present invention solves an error by verifying that a module has not been modified between when an error is identified and when a solution to the error is identified. An error processing application provided by the system and installed on a client system identifies multiple errors encountered by a client system, captures error information associated with multiple errors, prepares error reports comprising the captured error information for one or more of the errors, and transfers the error reports to the system. The error processing application verifies that a module has not been modified between when the error is identified and when the error reports are prepared. Thereafter an error report is transmitted to the system. The system typically verifies that it has a copy of module that generated the error. The present invention identifies a solution by comparing the error information, and, if a fixed solution does not exist in a centralized database, instead of rejecting the error and notifying a user, the system locates an algorithm for repairing the error and uses the algorithm to create a patched file in which the error has been corrected (e.g., by using the copy of module). The system transfers the patched file to the error processing application of the client. The error processing application then typically verifies that the module has not been modified before applying the patched file to resolve the error. Therefore, the system described herein provides a technical solution to the above discussed technical problem by providing a unique way to solve errors in dynamically changing web applications.

[0034] A "system environment", as used herein, may refer to any information technology platform of an enterprise (e.g., a national or multi-national corporation) and may include a multitude of servers, machines, mainframes, personal computers, network devices, front and back end systems, database system and/or the like.

[0035] Figure 1 provides a block diagram illustrating an environment 100 for a server system capable of automatically repairing web application runtime errors. As depicted in Figure 1, the operating environment 100 typically includes a server system 200 interacting with multiple client systems 300 (e.g., Client System 1, Client System 2, Client System 3 , Client System

N), other third party systems 202, and other storage systems 201, using a network 150. The server system 200 repairs the web application runtime errors encountered by the multiple client systems 300 by communicating with multiple client systems 300, the other storage systems 201, and the other third party systems 202. In some embodiments, the server system 200 may be a combination of one or more server systems coupled together. The server system 200 may be any computing device providing services to the client system. The server system 200 may be any type of computing device that may be connected to a network by landline or wireless access such as wireless local area network (WLAN) such as Wi-Fi based on the Institute of Electrical and Electronics Engineers' (IEEE) 802.11 standards, Bluetooth short-wavelength UHF radio waves in the ISM band from 2.4 to 2.485 GHz or other wireless access technology. In an embodiment of the present invention, the server system 200 resolves the web application runtime errors encountered by the multiple clients systems 300(Client System 1, Client System 2, Client System

3 , Client System N) simultaneously. The server system 200 typically has the capability to communicate with multiple client systems 300 and other third party systems 202 simultaneously.

[0036] In some embodiments, the other third party systems 202 may be any systems maintained by a third party institution containing one or more modules associated with web applications. In some embodiments, the other third party systems 202 may also include other modules associated with any other applications. The other storage systems 201 may be any systems coupled to the server system 200 capable of storing digital data. In some embodiments, the other storage systems 201 may be any expandable memory devices coupled to the server system 200.

[0037] Figure 2 provides a block diagram illustrating the server system 200, in greater detail, in accordance with embodiments of the invention. As illustrated in Figure 2, in one embodiment of the invention, the server system 200 includes one or more processing devices 220 operatively coupled to a network communication interface 210 and a memory device 230.

[0038] It should be understood that the memory device 230 may include one or more databases or other data structures/repositories. The memory device 230 also includes computer- executable program code that instructs the processing device 220 to operate the network communication interface 210 to perform certain communication functions of the server system 200 described herein. For example, in one embodiment of the server system 200, the memory device 230 includes, but is not limited to, a network server application 240, an error report processing application 250, a solution database 285, a strategy database 290, a module repository 295 comprising a file repository 298, and other computer-executable instructions or other data. In some embodiments, the solution database 285, the strategy database 290, the module repository 295 comprising the file repository 298 may be parts of a single database. In some embodiments, the solution database 285, the strategy database 290, the module repository 295 comprising the file repository 298 may be a part of other storage systems 201 coupled to the server system 200. [0039] The computer-executable program code of the network server application 240 or the error report processing application 250, may instruct the processing device 220 to perform certain logic, data-processing, and data-storing functions of the server system 200 described herein, as well as communication functions of the client system 300. The network server application 240 may include computer executable program code to perform certain

communication functions of the server system 200. The error report processing application 250 may include computer executable program code to perform certain processes described in the present application.

[0040] As used herein, a "communication interface" generally includes a modem, server, transceiver, and/or other device for communicating with other devices on a network. The network communication interface 210 is a communication interface having one or more communication devices configured to communicate with one or more other devices on the network 150, such as the multiple client systems 300, the other third party systems 202, and/or other storage systems 201. The processing device 220 is configured to use the network communication interface 210 to transmit and/or receive data and/or commands to and/or from the other devices connected to the network 150. In one embodiment of the present invention, the processing device 220 is configured to use the network communication interface 210 to transmit and/or receive data from multiple client systems 300 connected to the network 150 via an error processing application stored or installed in the multiple client systems 300.

[0041] Figure 3 presents a block diagram illustrating the client system 300, in accordance with embodiments of the invention. As illustrated in Figure 3, in one embodiment of the invention, the client system 300 includes one or more processing devices 320 operatively coupled to a network communication interface 310 and a memory device 330.

[0042] It should be understood that the memory device 330 may include one or more databases or other data structures/repositories. The memory device 330 also includes computer- executable program code that instructs the processing device 320 to operate the network communication interface 310 to perform certain communication functions of the client system 300 described herein. For example, in one embodiment of the client system 300, the memory device 330 includes, but is not limited to, a network server application 340, an error processing application 350, a downloading fix application 360, a file permission application 370, a web application 395 that includes one or more modules 390, each of which includes one or more files 393, and other computer-executable instructions or other data relevant to the client system 300. In one embodiment, downloading fix application 360, and the file permission application 370 may be part of the error processing application 350. In one embodiment, the error processing application 350 may be a plugin installed on the client system 200, wherein the plugin is provided by the server system 200.

[0043] The computer-executable program code of the network server application 340, the error processing application 350, the downloading fix application 360, and the file permission application 370 may instruct the processing device 320 to perform certain logic, data-processing, and data-storing functions of the client system 300 described herein. The network server application 340 performs all the communication functions of the client system 300.

[0044] As used herein, a "communication interface" generally includes a modem, server, transceiver, and/or other device for communicating with other devices on a network. The network communication interface 310 is a communication interface having one or more communication devices configured to communicate with one or more other devices on the network 150, such as the server system 200. The processing device 320 is configured to use the network communication interface 310 to transmit and/or receive data and/or commands to and/or from the other devices connected to the network 150.

[0045] Figure 4A presents a process flow 400 for illustrating an error capture process implemented by the error processing application 350 in the client system 300, in accordance with embodiments of the present invention. As shown in block 402, the error processing application 350 identifies one or more errors in the source code of a web application 395 encountered by the client system 300. In some embodiments, the client system 300 previously downloaded the error processing application 350 from the server system 200. In one embodiment of the present invention, the error processing application 350 identifies one or more errors in the web application 395 when the client system 300 executes the source code of the web application 395. The error processing application typically identifies the one or more errors by analyzing an execution log in the client system 300, wherein the execution log comprises the one or more errors encountered by the client system 300. The source code of the web application 395 is typically divided into one or more modules and the one or more modules are typically divided into one or more files, wherein the one or more files comprise parts of the source code. The present invention is described with respect to correcting errors in a web application, the present invention may be applicable to other typically of application. For example, the present invention may be applicable to any script-based application. In other words, the present invention may be used to corrected errors in any application having source code developed using scripting languages, such as PUP, Python, Perl, and/or the like. Typically, the system 200 identifies the one or more errors by analyzing the execution log after the client system 200 executes the web application 395 (or other script-based application). In typical embodiment, the one or more errors are runtime errors.

[0046] As shown in block 404, the error processing application 350 captures error information associated with each of the one or more errors. For each error, this captured error information typically includes a module name, a module version, a file name, an error message, an error line, and a first checksum of a client file associated with the error. In some

embodiments the first checksum is calculated using the MD5 algorithm. That said, other algorithms for calculating a checksum are within the scope of the present invention. In some embodiments, the error processing application 350 captures the module name, the module version, the file name, the error message, and the error line from the execution log. In some embodiments, the error processing application 350 captures the file name from the error log and calculates checksum of the client file with the file name associated with the error by accessing the memory device 330. In some embodiments, the one or more errors may be associated with the same module and the same file. In some embodiments, the one or more errors may be associated with same module and different files. In some other embodiments, the one or more errors may be associated with different modules and different files. In error processing application is continuously identifying the one or more errors and capturing the error information associated with the one or more errors.

[0047] As shown in block 406, the error processing application 350 creates a list of the one or more errors and stores the list in the client system 300, wherein the list comprises the error information associated with the one or more errors. For example, when the error processing application 350 identifies two hundred errors in step 402, the error processing application creates a list of two hundred errors and stores it in the memory of the client system 300. In some embodiments, the error processing application 350 updates the list simultaneously after identifying each of the one or more errors and capturing the error information. [0048] Periodically (e.g., hourly), the error processing application 350 prepares an error report containing information regarding captured errors. Before preparing the report, however, as shown in block 408, for each error to be included in the report, the error processing application 350 typically calculates a second checksum for the client file associated with the error before preparing the error report of captured errors. The second checksum, as well as any subsequent checksum, are typically calculated using the same checksum algorithm as the first checksum. The second checksum is typically a current real-time checksum of the client file associated with a particular error.

[0049] Using the first and second checksums, the error processing application 350 is able to verify that the client file associated with a particular error has not been changed after the identification of such error, as there typically exists a time difference between the identification of such error and preparation of the error report. In this regard, as shown in block 410, for each error to be included in the error report, the error processing application 350 determines if the second checksum matches the first checksum. By comparing the first checksum and the second checksum, the error processing application 350 is able to determine whether there has been a change to the client file associated with the error. If the error processing application 350 determines that the second checksum matches the first checksum for a particular error, the client file containing the particular error has not changed, and the process flow proceeds to block 412, wherein the error processing application includes the captured error information for such error in the error report. The error report may contain information regarding a single error or may include information regarding a plurality of errors. For each error included in the report, the report typically includes the following error information: the module name, the module version, the file name, the error message, error line, and the first checksum of the client file associated with (e.g., causing) the error. The error report is documentation of one or more errors in a format which is readable by the processing device 220 of the server system 200. As shown in block 411, if, for a particular error, the error processing application 350 determines that the second checksum does not match the first checksum, the client file causing the error changed, and information about such error is not included in the error report. In some embodiments, the error processing application 350 updates the list and marks the error as not resolved or not included in the error report. [0050] As shown in block 414, the error processing application 350 transfers the error report to the server system 200 from the client system 300. For the purposes of further explanation, the error report includes information regarding a first error. In addition, the error report may include information regarding other errors. In other embodiments, the error processing application 350 may send a separate error report for each captured error. In some embodiments, the error processing application 350 may group errors associated with the same file name and create a single error report. In other embodiments, the error processing application may group errors associated with the same module name and module version and create a single error report.

[0051] Figure 4B presents a process flow 400B illustrating error processing implemented by the error report processing application 250 in the server system 200, in accordance with embodiments of the present invention. As shown in block 416, the system 200 receives the error report from the client system 300 and typically stores the error report in the memory 230 of the server system 200. In some embodiments, the system 200 stores the error report in the other storage systems 201. In one embodiment of the present invention, the system 200 generates a unique identification number for each error report received from the client system 300. In such an embodiment, the system 200 typically transmits the generated unique identification number to the error processing application 350 client system 300, wherein the unique identification number may be used (e.g., by the error processing application 350) to check the status of the error report by the client system 300. In some embodiments, the error processing application 350 updates the list of the one or more errors stored in the client system 300 to include the unique identification number of the error report associated with each of the one or more errors.

[0052] As shown in block 418, the system 200 analyzes the error report to identify the module name, the module version, the filename, the error message, the error line, and the first checksum of the client file associated with the error. For example, the system 200 analyzes the error report to determine if any of this information is missing. If the system 200 determines that some information in the error report is missing, the system 200 notifies the client system about the missing information. In some embodiments, the system 200 requests the error processing application 350 in the client system 300 to provide the missing information.

[0053] As shown in block 420, the system 200 determines if a first module matching the module name and module version from the error report, exists in a module repository (e.g., the module repository 295). For example, where the error information regarding the first error includes a module name "A" and a module version 1.1 in the error report, the system 200 determines if a module with the name "A" and version 1.1 exists in the module repository 295 of the server system 200. The system also determines whether the first module contains a first file matching the filename.

[0054] In one embodiment of the present invention, if the module repository does not include the first module matching the module name and the first module containing the first file matching the filename from the error report, the system 200 proceeds to block 468 of Figure 4F. In some embodiments, if the module repository includes a module having the module name, but does not include a file having the filename, the system 200 proceeds to block 468 of Figure 4F. Figure 4F presents a continuation of the process flow 400B illustrating a process 400F for obtaining a module from a third party system. As shown in block 468, in response to determining that the module repository does not include the first module and the first file, the system 200 establishes a communication link with a third party system of the other third party systems 202. The third party system may be a verified source storing one or more modules. For example, the third party system may be an original developer of a module. As shown in block 470, the system 200 extracts the first module with the same module name and module version and including the first file with the same filename from the third party system. For example, the system 200 may download the first module including the first file from the third party system. In some embodiments, the system 200 may extract the first file instead of the entire first module. If the system 200 is unable to extract the first module with the same module name and module version and including the first file with the same filename from the third party system (or fails to extract the first file), then the system may implement the process flow described in Figure 4G. As shown in block 472, the system 200 identifies a fifth checksum of the first file extracted from the third party system. For example, the system 200 calculates the checksum of the first file extracted from the third party system. As shown in block 474, the system 200 validates the first file extracted from the third party system by determining if the fifth checksum matches the first checksum to determine a matching profile. For example, the system 200 may download the first module including the first file from the third party system and may verify that the first file extracted from the third party system is same as the client file associated with a particular error. If the system 200 determines a matching file based on determining that the fifth checksum matches the first checksum, the process flow proceeds to block 478. As shown in block 478, the system 200 stores the first module in the module repository 295 and the first file in the file repository 298, wherein the first file is the matching file, and proceeds to block 432 of Figure 4C. The matching file comprises the same part of the source code existing in the client file associated with the error. If the system 200 determines that the fifth checksum does not match the first checksum, the system 200 notifies the client system as shown in block 476 and may reject the error report (or the particular error in the error report). In some embodiments, the system 200 in response to determining that the fifth checksum does not match the first checksum, implements the process flow described in Figure 41.

[0055] In another embodiment of the present invention, if the module repository 295 does not include the first module, namely a module having same module name and the first module containing a file having the same filename, the system 200 proceeds to block 482 of Figure 4G. In some embodiments, if the module repository includes a module having the same module name, but does not include a file having the same filename, the system 200 proceeds to block 482 of Figure 4G. Figure 4G presents a continuation of the process flow 400B illustrating a process 400G for obtaining a module from the client system. As shown in block 482, in response to determining that the module repository does not include a matching module, the system 200 sends a request to the error processing application 350 in the client system 300 to provide the first module with the same module name and module version and including the first file with the same filename, wherein the request includes unique identification number of the error report. In one embodiment, the error processing application 350 in response to receiving the request to provide the first module, validates the request to verify that the unique identification number is associated with any of the one or more errors in the list. The error processing application 350 extracts the module with the module name and module version including the file with the file name from the memory device 330. The extracted file with the file name from the memory device 330 is a copy of the client file associated with the error. In some embodiments, the error processing application 350 archives the module with the module name and module version including the file with the file name, wherein archiving the module converts the module into binary data. The error processing application 350 transfers the binary data associated with the archive to the system 200. As shown in block 484, the system 200 receives the first module with the module name and module version including the first file with the file name from the error processing application 350. In some embodiments, the system 200 receives the first module in an archived form. The system 200 un-archives the first module and proceeds to block 486. In some embodiments, the system 200 may receive the first file instead of the entire first module. If the system 200 is unable to receive the first module with the same module name and module version and including the first file with the same filename from the client system 300 (or fails to receive the first file), then the system 200 may implement the process flow described in Figure 4F. As shown in block 486, the system 200 identifies a sixth checksum of the first file extracted from the client system 300. For example, the system 200 calculates the checksum of the first file extracted from the client system. As shown in block 488, the system 200 validates the first file extracted from the client system by determining if the sixth checksum matches the first checksum to determine the matching file. For example, the system 200 may download the first module including the first file from the client system and may verify that the first file extracted from the client system is same as the client file associated with a particular error. If the system 200 determines the matching file based on determining that the sixth checksum matches the first checksum, the process flow proceeds to block 490. As shown in block 490, the system 200 stores the first module in the module repository 295 and the first file in the file repository 298 and proceeds to block 432 of Figure 4C. If the system 200 determines that the sixth checksum does not match the first checksum, the system 200 notifies the client system as shown in block 489 and may reject the error report (or the particular error in the error report). In some embodiments, the system 200, in response to determining that the sixth checksum does not match the first checksum, implements the process flow described in Figure 4H.

[0056] Next, the system typically validates the first file (e.g., by determining that the first file is identical to the client file causing the error). In this regard, as shown in block 422, in response to determining that the first module with the module name and module version and the first module including the first file with the filename exists in the module repository 295, the system 200 identifies a third checksum of the first file existing in the module repository 295. As shown in block 424, the system 200 determines if the third checksum matches the first checksum to determine the matching file. For example, if the third checksum matches the first checksum, then the first file stored in the module repository 295 is expected to be identical to the client file associated (e.g., causing) the error. Typically, if the system 200 determines that the third checksum matches the first checksum, the process flow proceeds to block 432 in Figure 4C. [0057] In one embodiment, if the system 200 determines that the third checksum does not match the first checksum, the system 200 implements process flows described in Figure 4H. For example, the first module stored in the module repository may not include the first file matching the checksum of the client file associated with the error. Figure 4H presents a continuation of the process flow 400B illustrating a process 400H for obtaining the second file from the third party system. As shown in block 491, the system 200 establishes a communication link with the third party system. As shown in block 492, the system 200 extracts a second file with the filename from the third party system. For example, the system 200 downloads the second file with the filename associated with the client file containing the error. In some embodiments, the system 200 extracts a second module with the same module name and the module version containing the second file with the same filename as the client file associated with the error. For example, the system 200 downloads the entire module with the module name and module version containing the second file with the same filename as opposed to downloading only the second file. If the system 200 is unable to extract the second module with the same module name and module version and including the second file with the same filename from the third party system (or fails to extract the second file), then the system may implement the process flow described in Figure 41. As shown in block 493, the system 200 validates the second file extracted form the third party system by identifying a seventh checksum of the second file and determining if the seventh checksum matches the first checksum to find the matching file as shown in block 494. For example, the system 200 may download the second file from the third party system and may verify that the second file extracted from the third party system is same as the client file associated with a particular error. If the system 200 determines that the seventh checksum does not match the first checksum, the system 200 notifies the client system 300 as shown in block 495, and may reject the error report (or the particular error report). In some embodiments, the system 200 in response to determining that the seventh checksum does not match the first checksum, implements the process flow described in Figure 41. If the system 200 determines that the seventh checksum matches the first checksum, the process flow proceeds to block 432 of Figure 4C.

[0058] In another embodiment, if the system 200 determines that the third checksum does not match the first checksum, the system 200 implements the process flow described in Figure 41. For example, the first module stored in the module repository may not include the first file matching the checksum of the client file associated with the error. Figure 41 presents a continuation of the process flow 400B illustrating a process 4001 for obtaining the second file from the client system. As shown in block 497, in response to determining that the system 200 sends a request to the error processing application 350 in the client system 300 to provide the second file with the same filename, wherein the request includes unique identification number of the error report. In one embodiment, the error processing application 350 in response to receiving the request to provide the first module, validates the request to verify that the unique

identification number is associated with any of the one or more errors in the list. The error processing application 350 extracts the second file with the filename from the memory device 330. The extracted file with the filename from the memory device 330 is a copy of the client file associated with the error. In some embodiments, the error processing application 350 archives the second file with the filename, wherein archiving converts the second file into binary data. The error processing application 350 transfers the binary data associated with the second file to the system 200. In some embodiments, the system 200 may send a request to the error processing application 350 to provide the second module with the same module name and module version containing the second file with the same filename as the client file associated with the error. As shown in block 498, the system 200 receives the second file with the filename from the error processing application 350. In some embodiments, the system 200 receives the second file with the filename in an archived form. If the system 200 is unable to receive the second module with the same module name and module version and including the second file with the same filename from the client system 300 (or fails to receive the second file), then the system 200 may implement the process flow described in Figure 4H. The system 200 un- archives the second file and proceeds to block 499. As shown in block 499, the system 200 identifies an eighth checksum of the second file extracted from the client system. For example, the system 200 calculates the checksum of the second file extracted from the client system. As shown in block 500, the system 200 validates the second file extracted from the client system by determining if the eighth checksum matches the first checksum to determine the matching file. For example, the system 200 may download the second file from the client system and may verify that the second file extracted from the client system is same as the client file associated with a particular error. If the system 200 determines the matching file based on determining that the eighth checksum matches the first checksum, the process flow proceeds to block 490. As shown in block 490, the system 200 stores the second file in the file repository 298 and proceeds to block 432 of Figure 4C. If the system 200 determines that the eighth checksum does not match the first checksum, the system 200 notifies the client system as shown in block 501 and may reject the error report (or the particular error in the error report). In some embodiments, the system 200, in response to determining that the eighth checksum does not match the first checksum, implements the process flow described in Figure 4H.

[0059] Figure 4C presents a database solution search process flow 400C implemented by the server system 200, in accordance with embodiments of the present invention. As shown in block 432, the system 200 initiates an error fixing process based on determining the matching file. The error fixing process is illustrated in Figure 4E from block 434 to block 442 and in Figure 4F from block 446 to block 453.

[0060] In block 434, the system 200 performs a literal search based on the error information, wherein the literal search comprises identifying a patch file in the solution database 285 for the same error message associated with the same module name and module version, the same file name and the same error line, wherein the patch file resolves the error associated with the error message. The patch file is typically a corrected version of the file that caused a particular error. The patch files in the solution database may have been previously stored in response to processing previous error reports. For example, if the error message in the error report associated with an error comprises "unidentified index Q", the system 200 performs the literal search to find an existing patch file in the solution database 285 for the error message "unidentified index Q" associated with the same module name and module version, the same file name associated with error, and the same error line. As shown in block 436, the system 200 determines if the literal search has identified the patch file for the error message in the solution database 285. If the system 200 determines that the literal search has identified the patch file for the error message, the process flow proceeds to block 442. If the system 200 determines that the literal search has not identified the patch file for the error message in the solution database 285, the process flow proceeds to block 438. In some embodiments, the system 200 identifies error messages similar to the error message with the exception of dynamic information and proceeds to block 438. For example, the system 200 identifies the patch file for a similar error having the same non-dynamic information and having the same module name and module version, the same file name, and the same error line. [0061] As shown in block 438, the system 200 performs a regular expression search, wherein the regular expression search comprises identifying the patch file in the solution database 285 matching the non-dynamic information in the error message, wherein the patch file is associated with the same module name and module version, the same filename, and the same error line. For example, if the first error message comprises "unidentified index Q" which is associated with a module name "A", a module version 1.1, a file name "B", and an error line "12", the system performs the regular expression search to strip or otherwise ignore the dynamic information "Q" from the error message and identify all the errors associated with non-dynamic error message "unidentified index" which are associated with the module name "A", the module version 1.1, the file name "B", and the error line " 12". As used herein, dynamic information in an error message is information that is independent of the content of a file that caused an error. Thus, even if two identical files cause the same error, dynamic information contained in a generated error message may be different. For example, dynamic information may include the time an error occurred or the name of a user accessing a file at the time of an error.

[0062] As shown in block 440, the system determines if the regular expression search has identified the patch file in the solution database 285. If the system 200 determines that the regular expression search has identified the patch file in the solution database 285, the process flow proceeds to block 442. If the system 200 determines that the regular search has not identified the patch file, the process flow proceeds to block 446 of Figure 4D. As shown in block 442, the system 200, sends a unique patch file identification number associated with the patch file to the error processing application, wherein the error processing application 350 in the client system 300 may subsequently download the patch file using the unique patch file identification number. In some embodiments, the error processing application 350 communicates with the downloading fix application 360 and downloads the patch file associated with the unique patch file identification number to resolve the error.

[0063] Figure 4D presents an error repairing process flow 400D implemented by the server system 200, in accordance with embodiments of the present invention. As shown in block 446, the system 200 determines that the error has not been fixed in the process flow 400C described in Figure 4C. For example, the system 200 verifies that a patch file for a first error has not been identified. As shown in block 447, the system 200 typically performs static code analysis to parse source code of the matching file to convert the source code into an abstract syntax tree based on determining that the error has not been fixed. The static code analysis is a method for analyzing source code without executing the source code. The static code analysis provides an understanding of the source code structure. For example, the system 200 converts the source code of the matching file into the abstract syntax tree representing the abstract syntactic structure of the source code, wherein the abstract syntax tree comprises nodes, wherein each node denotes a construct occurring in the source code.

[0064] As shown in block 449, the system 200 identifies a failing node based on the error information, such as the error line and the error message. For example, the system identifies that the error line number is " 12" and identifies a node involved with the line number "12". As shown in block 450, the system 200 based on the error message, identifies and applies a first strategy from one or more strategies in the strategy database 290 to fix the failing node. For example, different strategies exist for different type of error messages in the strategy database. For example, the system 200 identifies that the type of the first error belongs to category "A" and applies a first strategy linked to category "A", wherein the first strategy may include an algorithm replacing the identified failing node with another node, and wherein the type of the first error is identified using the error information. In some embodiments, the one or more strategies may include algorithms for deleting the failing node, updating the failing node, overriding the failing node, editing the failing node and/or the like. In one embodiment, if the system 200 is unable to identify the failing node based on the error message, the system 200 notifies the client system 300, wherein the notification may indicate that the first error cannot be fixed. In one embodiment, the system 200 notifies the client system 300 that the first module is encrypted and the first error cannot be fixed. In another embodiment, the system 200 notifies the client system 300 that the error report has been corrupted and the first error cannot be fixed. That said, if the error report includes information about multiple errors, the system may, instead of rejecting the entire report, reject the error that cannot be fixed and proceed with processing the next error in the report. In some embodiments, the entire error report or a particular error in the report is rejected if the system is unable to obtain a module and/or file matching the module and file associated with the particular error (e.g., even after requesting such module and file from the client system 300 or from a third party system).

[0065] As shown in block 451, the system 200 converts the abstract syntax tree that has been corrected to a new source code and stores the new source code in a new patch file in the solution database 285. For example, the new patch file is a fixed version of the client file that does not include the failing node causing the error. As shown in block 452, the system 200 generates the unique patch file identification number for the new patch file. The new patch file also includes the error information such as the module name, the module version, the file name, the error message, the first checksum and the error line. In some embodiments, the new patch file stored in the solution database 285, may be used to solve another error report having similar error information. The error processing application 350 may subsequently use the unique patch file identification number to download the patch file from the server system 200. The system 200 repeats the process flow 400B, 400C, and 400D for all error reports associated with each of the identified one or more errors in the list. If an error report includes multiple errors, the process flow 400B, 400C, and 400D may be repeated for each error in the report. When processing multiple errors, the system 200 may process the errors in parallel, in series, or a combination thereof. As shown in block 453, the system 200 transmits the unique identification number associated with the new patch file to the error processing application 350 and the process flow proceeds to block 456 of Figure 4E.

[0066] Although the process flow 400C is describes as converting the source code of the matching file to an abstract syntax tree before applying a strategy to correct the error, it is within the scope of the present invention to apply a strategy (e.g., algorithm for fixing the error) directly to the source code of the matching file without converting the matching file to an abstract syntax tree.

[0067] In some embodiments, if the system 200 is unable to identify the first strategy from the one or more strategies based on the error information associated with the error, the system 200 flags the error report associated with the error for a manual review. In some embodiments, the manual review may result in manual creation of a patch file to fix the error associated with the error report which was not fixed using the error repairing process described in Figure 4C and Figure 4D.

[0068] Figure 4E presents an error patching process flow 400E implemented by the error processing application 350, in accordance with embodiments of the present invention. As shown in block 456, the error processing application receives the unique patch file identification number from the server system. As shown in block 458, the system updates the list to include the unique patch file identification number for each of the one or more errors. [0069] As shown in block 460, the error processing application 350 determines if the client file associated with the error can be overwritten with the patch file. For example, the client system 300 may protect the client file stored in the memory device 330by placing a restriction on the client file to prevent overwriting. If the error processing application 350 determines that the client file associated with the error cannot be overwritten, the error processing application 350 communicates with the file permission application 370 to notify the client system 300 as shown in block 461, wherein the notification alerts a user managing the client system 300. The file permission application 370 acquires all necessary permissions required to resolve the one or more errors. In one embodiment, the notification comprises a permission request to overwrite the client file associated with the error, wherein the error processing application transfers the permission request to the file permission application 370 in the client system 300. The file permission application 370 sends a notification to a user managing the client system 300 to provide permission to overwrite the client file. If the error processing application determines that the client file associated with the error can be overwritten, the process flow proceeds to block 462.

[0070] As shown in block 462, the error processing application 350 identifies a fourth checksum associated with the client file, wherein the fourth checksum is the current real-time checksum of the client file. As shown in block 464, the error processing application 350 determines if the fourth checksum matches the first checksum. For example, the error processing application 350 before overwriting the client file, checks whether the file associated with the error has been amended after generation of the error report. If the error processing application 350 determines that the fourth checksum does not match the first checksum, the error processing application 350 notifies the client system 300 as shown in block 465. For example, the error processing application 350 determines that the file associated with the error has been amended after preparing the error report and determines that the patch file with the unique patch file identification number is not applicable to resolve the error. The error processing application 350 notifies the client system 300.

[0071] As shown in block 466, the error processing application 350 overwrites the client file with the patch file containing the fix based on determining that the fourth checksum matches the first checksum. In some embodiments, after overwriting the client file with the patch file containing the fix, the error processing application 350 updates the list of the one or more errors stored in the client system 300 by marking the error as resolved. In some embodiments, the user managing the client system 300 downloads the patch files using the unique patch file

identification number by communicating with the error processing application 350.

[0072] As will be appreciated by one of skill in the art, the present invention may be embodied as a method (including, for example, a computer-implemented process, a business process, and/or any other process), apparatus (including, for example, a system, machine, device, computer program product, and/or the like), or a combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, and the like), or an embodiment combining software and hardware aspects that may generally be referred to herein as a "system." Furthermore, embodiments of the present invention may take the form of a computer program product on a computer-readable medium having computer-executable program code embodied in the medium.

[0073] Any suitable transitory or non-transitory computer readable medium may be utilized. The computer readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples of the computer readable medium include, but are not limited to, the following: an electrical connection having one or more wires; a tangible storage medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), or other optical or magnetic storage device.

[0074] In the context of this document, a computer readable medium may be any medium that can contain, store, communicate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer usable program code may be transmitted using any appropriate medium, including but not limited to the Internet, wireline, optical fiber cable, radio frequency (RF) signals, or other mediums.

[0075] Computer-executable program code for carrying out operations of embodiments of the present invention may be written in an object oriented, scripted or unscripted

programming language. However, the computer program code for carrying out operations of embodiments of the present invention may also be written in conventional procedural programming languages, such as the "C" programming language or similar programming languages.

[0076] Embodiments of the present invention are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and/or combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-executable program code portions. These computer- executable program code portions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a particular machine, such that the code portions, which execute via the processor of the computer or other programmable data processing apparatus, create mechanisms for

implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0077] These computer-executable program code portions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the code portions stored in the computer readable memory produce an article of manufacture including instruction mechanisms which implement the function/act specified in the flowchart and/or block diagram block(s).

[0078] The computer-executable program code may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer- implemented process such that the code portions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block(s). Alternatively, computer program implemented steps or acts may be combined with operator or human implemented steps or acts in order to carry out an embodiment of the invention.

[0079] As the phrase is used herein, a processor may be "configured to" perform a certain function in a variety of ways, including, for example, by having one or more general- purpose circuits perform the function by executing particular computer-executable program code embodied in computer-readable medium, and/or by having one or more application-specific circuits perform the function. [0080] Embodiments of the present invention are described above with reference to flowcharts and/or block diagrams. It will be understood that steps of the processes described herein may be performed in orders different than those illustrated in the flowcharts. In other words, the processes represented by the blocks of a flowchart may, in some embodiments, be in performed in an order other that the order illustrated, may be combined or divided, or may be performed simultaneously. It will also be understood that the blocks of the block diagrams illustrated, in some embodiments, merely conceptual delineations between systems and one or more of the systems illustrated by a block in the block diagrams may be combined or share hardware and/or software with another one or more of the systems illustrated by a block in the block diagrams. Likewise, a device, system, apparatus, and/or the like may be made up of one or more devices, systems, apparatuses, and/or the like. For example, where a processor is illustrated or described herein, the processor may be made up of a plurality of microprocessors or other processing devices which may or may not be coupled to one another. Likewise, where a memory is illustrated or described herein, the memory may be made up of a plurality of memory devices which may or may not be coupled to one another.

[0081] While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations and modifications of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.

Claims

1. A system for repairing application errors, comprising:

a processor;

a memory; and

an error report processing application stored in the memory, executable by the processor and configured for:

receiving error information from a client device, wherein the error information comprises information related to an error identified by the client device after executing a client file, wherein the error information comprises a file identifier of the client file and a checksum of the client file;

determining that a repository comprises a matching file having a file identifier that matches the file identifier of the client file;

validating the matching file, wherein validating the matching file comprises: calculating a checksum of the matching file;

comparing the checksum of the matching file to the checksum of the client file;

determining that the checksum of the matching file matches the checksum of the client file;

in response to validating the matching file, identifying a solution to the error, wherein the solution comprises a patched file.

2. The system according to claim 1, wherein the error report processing application is configured for:

determining that the repository does not comprise the matching file;

in response to determining that the repository does not comprise the matching file, transmitting a request for the matching file to a third party system;

receiving the matching file from the third party system.

3. The system according to claim 1, wherein the error report processing application is configured for:

determining that the repository does not comprise the matching file; in response to determining that the repository does not comprise the matching file, transmitting a request for the matching file to the client device;

receiving the matching file from the client device.

4. The system according to claim 3, wherein the request for the matching file is transmitted to the client device in response to determining that a third party system does not have the matching file.

5. The system according to claim 1, wherein the error report processing application is configured for:

determining that a repository comprises an existing file having a file identifier that matches the file identifier of the client file;

validating the existing file, wherein validating the existing file comprises:

calculating a checksum of the existing file;

comparing the checksum of the existing file to the checksum of the client file; determining that the checksum of the existing file does not match the checksum of the client file;

in response to determining that the checksum of the existing file does not match the checksum of the client file, requesting a copy of the client file from the client device;

receiving the copy of the client file from the client device;

storing the copy of the client file in the repository, wherein the copy of the client file stored in the repository is the matching file.

6. The system according to claim 5, wherein determining that the repository comprises the matching file comprises determining that the copy of the client file has been stored in the repository.

7. The system according to claim 5, wherein determining that the repository comprises the matching file is performed after receiving the copy of the client file from the client device.

8. The system according to any one of claims 1-7: wherein the error information comprises an error identifier of the error;

wherein identifying the solution to the error comprises:

searching a solution database for a solution record having both (i) a file identifier that matches the file identifier of the client file and (ii) an error identifier that matches the error identifier of the error;

identifying a matching solution record, wherein the matching solution record is associated with the patched file.

9. The system according to claim 8:

wherein the error identifier of the error comprises a line number of the error and an error message of the error;

wherein the matching solution record has (i) a file identifier that matches the file identifier of the client file, (ii) a line number that matches the line number of the error, and (iii) an error message that literally matches the error message of the error.

10. The system according to claim 8:

wherein the matching solution record has (i) a file identifier that matches the file identifier of the client file, (ii) a line number that matches the line number of the error, and (iii) an error message that matches, with the exception of dynamic information, the error message of the error.

11. The system according to claim 10:

wherein identifying a matching solution record comprises:

determining that the solution database does not include a solution record having (i) a file identifier that matches the file identifier of the client file, (ii) a line number that matches the line number of the error, and (iii) an error message that literally matches the error message of the error; performing a regular expression search to determine that the error message of the matching solution record matches, with the exception of dynamic information, the error message of the error.

12. The system according to any one of claims 1-7, wherein identifying the solution to the error comprises:

identifying, in a strategy database, a repair algorithm for correcting the error;

applying the repair algorithm to the matching file to create the patched file.

13. The system according to claim 12, wherein applying the repair algorithm to the matching file to create the patched file comprises:

using static code analysis to parse source code of the matching file and convert the source code into an abstract syntax tree;

identify a node of the abstract syntax tree associated with the error;

applying the repair algorithm to fix the node associated with the error and create the patched file.

14. The system according to any one of claims 12-13 :

wherein the error information comprises an error identifier of the error;

wherein identifying the solution to the error comprises determining that a solution database does not have a matching solution record having both (i) a file identifier that matches the file identifier of the client file and (ii) an error identifier that matches the error identifier of the error;

where identifying the repair algorithm for correcting the error and applying the repair algorithm to the matching file to create the patched file are performed in response to determining that the solution database does not have the matching solution record.

15. The system according to claim 14, wherein identifying the solution to the error comprises storing the patched file in the solution database.

16. The system according to any one of claims 1-15, wherein the error report processing application is configured for notifying the client device that the solution to the error has been identified.

17. The system according to any one of claims 1-16, wherein the error report processing application is configured for transmitting a client error processing application to the client device.

18. The system according to claim 17, wherein the client error processing application, when executed by the client device, is configured to cause the client device to:

capture the error information;

transmit the error information to the system.

19. The system according to claim 17, wherein the client error processing application, when executed by the client device, is configured to cause the client device to:

capture the error information, the captured error information comprising the checksum of the client file;

subsequently, calculate a second checksum of the client file;

compare the second checksum of the client file to the checksum of the client file;

determine that the second checksum of the client file matches the checksum of the client file;

in response to determining that the second checksum of the client file matches the checksum of the client file, add the error information to an error report and transmit the error report to the system.

20. The system according to any one of claims 17-19, wherein the client error processing application, when executed by the client device, is configured to cause the client device to: receive, from the system, a notification of the patched file;

calculate a current checksum of the client file;

compare the current checksum of the client file to the checksum of the client file; determine that the second checksum of the client file matches the checksum of the client file;

in response to determining that the current checksum of the client file matches the checksum of the client file, download the patched file from the system;

overwriting the client file with the patched file.

21. The system according to any one of claims 1-18, wherein receiving the error information from the client device comprises receiving an error report from the client device.

22. The system according to any one of claims 1-21, wherein the file identifier of the client file comprises a filename of the client file.

23. The system according to any one of claims 1-22, wherein the file identifier of the client file comprises a filename of the client file, a module name of a module containing the client file, and a module version of the module containing the client file.

24. The system according to any one of claims 1-23, wherein the client file is a file of a script-based application.

25. A method for repairing application errors, comprising:

validating the matching file, wherein validating the matching file comprises:

calculating a checksum of the matching file;

comparing the checksum of the matching file to the checksum of the client file; determining that the checksum of the matching file matches the checksum of the client file; in response to validating the matching file, identifying a solution to the error, wherein the solution comprises a patched file.

26. The method of claim 25, comprising:

determining that the repository does not comprise the matching file;

receiving the matching file from the third party system.

27. The method of claim 25, comprising:

determining that the repository does not comprise the matching file;

in response to determining that the repository does not comprise the matching file, transmitting a request for the matching file to the client device;

receiving the matching file from the client device.

28. The method of claim 27, wherein the request for the matching file is transmitted to the client device in response to determining that a third party system does not have the matching file.

29. The method of claim 25, comprising:

validating the existing file, wherein validating the existing file comprises:

calculating a checksum of the existing file;

receiving the copy of the client file from the client device; storing the copy of the client file in the repository, wherein the copy of the client file stored in the repository is the matching file.

30. The method of claim 29, wherein determining that the repository comprises the matching file comprises determining that the copy of the client file has been stored in the repository.

31. The method of claim 29, wherein determining that the repository comprises the matching file is performed after receiving the copy of the client file from the client device.

32. The method of any one of claims 25-31 :

wherein the error information comprises an error identifier of the error;

wherein identifying the solution to the error comprises:

33. The method of claim 32:

34. The method of claim 32:

35. The method of claim 34:

wherein identifying a matching solution record comprises:

determining that the solution database does not include a solution record having (i) a file identifier that matches the file identifier of the client file, (ii) a line number that matches the line number of the error, and (iii) an error message that literally matches the error message of the error;

performing a regular expression search to determine that the error message of the matching solution record matches, with the exception of dynamic information, the error message of the error.

36. The method of any one of claims 25-31, wherein identifying the solution to the error comprises:

applying the repair algorithm to the matching file to create the patched file.

37. The method of claim 36, wherein applying the repair algorithm to the matching file to create the patched file comprises:

identify a node of the abstract syntax tree associated with the error;

38. The method of any one of claims 36-37:

wherein the error information comprises an error identifier of the error;

39. The method of claim 38, wherein identifying the solution to the error comprises storing the patched file in the solution database.

40. The method of any one of claims 25-39, comprising notifying the client device that the solution to the error has been identified.

41. The method of any one of claims 25-40, comprising transmitting a client error processing application to the client device.

42. The method of claim 41, wherein the client error processing application, when executed by the client device, is configured to cause the client device to:

capture the error information;

transmit the error information to the system.

43. The method of claim 41, wherein the client error processing application, when executed by the client device, is configured to cause the client device to:

subsequently, calculate a second checksum of the client file;

44. The method of any one of claims 41-43, wherein the client error processing application, when executed by the client device, is configured to cause the client device to: receive, from the system, a notification of the patched file;

calculate a current checksum of the client file;

compare the current checksum of the client file to the checksum of the client file;

overwriting the client file with the patched file.

45. The method of any one of claims 25-42, wherein receiving the error information from the client device comprises receiving an error report from the client device.

46. The method of any one of claims 25-45, wherein the file identifier of the client file comprises a filename of the client file.

47. The method of any one of claims 25-46, wherein the file identifier of the client file comprises a filename of the client file, a module name of a module containing the client file, and a module version of the module containing the client file.

48. The method of any one of claims 25-47, wherein the client file is a file of a script- based application.