A humanoid robot front-end bridge fault-tolerant routing method based on method name standardization and mapping table degradation

Abstract

The present application aims at the problem of inconsistency between front-end method name and back-end method name caused by cross-language character encoding conversion in the desktop application front-end bridging scene, and discloses a front-end bridging fault-tolerant routing method. After the standardization processing of removing blank symbols, converting to lowercase and replacing underscores with hyphens is performed on the front-end incoming method name, the method name is sequentially searched in a method registry and a degradation mapping table. The degradation mapping table is automatically constructed by reflecting the method registry during system initialization, and a hyphen variant key and an underscore reduction variant key are generated for each registered method, so that the mapping file does not need to be manually maintained. All exceptions are uniformly serialized into a structured response containing an exception type field.

Description

Technical Field

[0001] This invention relates to the field of front-end bridging technology for desktop applications, specifically to a front-end bridging fault-tolerant routing method based on method name standardization and mapping table degradation. The method performs route lookup after standardizing the method name passed from the front end by removing whitespace, lowercase, and normalizing symbols. It also solves cross-platform encoding compatibility issues by combining a pre-registered degradation mapping table and serializes all call exceptions into a structured JSON response. Background Technology

[0002] When implementing bridging communication between the front-end and back-end in desktop applications, the front-end calls methods registered on the back-end using property access syntax. The bridging mechanism converts the front-end's property access chain into string parameters for method routing on the back-end. This bridging mechanism provides a lightweight technology stack integration for communication between the web front-end and back-end business logic of a humanoid robot console. However, front-end bridging implementations across different operating systems expose an encoding issue affecting method name routing, stemming from the interplay of three technical factors: In the first layer, the bridging component, within a specific operating system backend, employs an operating system-level string passing mechanism when converting frontend attribute access links into string parameters in the backend process. When the string crosses the boundary between the frontend script engine and the backend runtime, the character encoding undergoes three conversions. During this process, some characters—especially hyphens (U+002D, HYPHEN-MINUS) and underscores (U+005F, LOW LINE)—are incorrectly converted between each other in the conversion path: a method name with a hyphen called by the frontend becomes an underscore when received by the backend, while a method name with an underscore called by the frontend becomes a hyphen in another scenario. This uncertain bidirectional conversion makes it impossible for methods registered by the backend to be called by the frontend in a stable manner. The second layer of the existing solution handles this problem by directly throwing an exception. When the method name passed from the front end cannot be found in the method registry of the bridging component, a property error or key error exception is thrown. The exception message is passed back to the front end through the internal exception pipeline of the bridge, and the front end console outputs an unformatted backend exception stack trace. When front-end developers encounter the error message "Property error: The object does not have a certain property", they need to check the method name registered on the back end, and then fall back to the front-end code to check line by line whether it is a spelling error on the front end or an encoding conversion error in the bridging component. This troubleshooting process is triggered an average of 3 to 4 times per week in a front-end team of 5 or more people, and each time it takes about 25 minutes. The third layer involves inconsistent registry routing due to cross-platform encoding differences. When the same front-end code runs on different operating systems, the encoding behavior of method names varies across platforms. Taking the registration back-end method `submit_login_login_1` as an example: on the first operating system, the back-end receives the same string when the front-end calls this method name (which includes underscores); on the second operating system, when the front-end also calls this method name, all underscores in the string received by the back-end are converted to hyphens. This means that if the back-end performs an exact match using only the original registration name as the key, the search will fail on different operating systems. In summary, the front-end bridging of desktop applications suffers from cross-language encoding compatibility issues, which makes method name routing lack fault tolerance. A fault-tolerant routing method is needed that can handle encoding differences and provide structured exception responses. Summary of the Invention

[0003] This invention provides a front-end bridging fault-tolerant routing method based on method name standardization and mapping table degradation. After performing triple standardization processing on the method name passed from the front end (removing whitespace, converting to lowercase, and replacing hyphens with underscores), a three-layer route lookup is performed (exact matching → standardized name matching → degradation mapping table matching). At the same time, all call exceptions are serialized into a structured JSON response containing a success identifier, error information, and exception type name. The technical solution of the method corresponds to the following independent steps: Step 1: Receive the method name string from the frontend. This string is extracted from the frontend call chain and passed to the backend method router by the bridging component's internal mechanism. Step two involves performing triple normalization on the method name: (1) removing all whitespace characters at the beginning, end, and in the middle of the string; (2) converting all uppercase letters in the string to lowercase letters to eliminate case differences; and (3) replacing all hyphens in the string with underscores. The normalization operation ensures that regardless of the variant form that the bridging component's encoding path converts the front-end method name to, it is ultimately reduced to a uniform standard format. Step 3: Perform an exact search in the method registry using the standardized method name as the key and the backend callable object as the value. If a match is found, the call request is directly dispatched to the corresponding processing function. Step four: If step three does not find a match, search the degradation mapping table for the mapping target of the normalized method name. The degradation mapping table is automatically built during system initialization: it iterates through all key-value pairs in the method registry, generating multiple possible front-end bridging encoding variants as degradation keys for each registered method. Specific generation rules include, but are not limited to: variants that replace underscores with hyphens, and variants that reduce multiple consecutive underscores to a single underscore. Each variant key maps back to the original normalized method name. When a normalized method name is matched in the degradation mapping table, the corresponding original normalized method name is retrieved, and then the call is executed in the method registry using that normalized name. Step 5: If no method is found in steps 3 and 4, a structured error message indicating that the method is not registered is generated and the process is returned. Step six: Dispatch the call request to the found handling function and catch all exceptions (including type errors, value errors, attribute errors, and custom exceptions in business logic) throughout the entire call execution process. Step 7: Serialize exceptions into structured responses. A successful call returns a structured response containing a success flag and data fields; an exception occurs when a structured response is returned containing a false success flag, an error message string, and an exception type name. The front-end can uniformly process all responses based on the success flag's decision branch. Beneficial effects and causal chain: First, consistency in cross-platform method name routing. In tests of mainstream desktop application front-end bridging solutions, the front-end called the same back-end method with various method name variations: normal format with underscores, all hyphens, mixed case, extra spaces, and extra underscores. Under traditional exact match routing without this solution, only the normal format succeeded. However, under this solution's triple normalization and fallback mapping, all variations successfully routed. The causal chain is: cross-language encoding uncertainty → method name variations → triple normalization → unique standard form → exact match or fallback match hit → successful routing → elimination of the "method not found class" front-end failure. Second, a unified consumption model for exception responses. In traditional solutions, backend exceptions are converted into generic frontend error objects by the time they reach the frontend via the bridging internal pipeline, resulting in the loss of exception type information and structured fields. If the frontend code needs to distinguish between communication timeouts and parameter validation failures, it needs to write string matching logic to check if the error message contains a specific substring. This makes the code fragile and dependent on the unchanged wording of the exception message. This solution serializes exceptions into structured responses with exception type fields. The frontend can use these fields for precise type branching, significantly improving code maintainability and robustness. The causal chain is: full exception capture → structured extraction of exception information → explicit transmission of exception type fields → unified frontend type-based branching → significant reduction in exception handling failures. Third, the automatic construction of the degradation mapping table provides a zero-configuration experience. The degradation mapping table is automatically built by traversing the method registry at system startup, eliminating the need for developers to manually maintain mapping files. When a developer adds a new method registration, the mapping table is automatically updated synchronously, eliminating the window of opportunity caused by forgetting to update the mapping table after adding a method, leading to degradation routing failure. The causal chain is: automatic construction by traversing the registry → automatic generation of variant keys → new methods take effect immediately → zero manual configuration → zero operational burden. Attached Figure Description Figure 1 This is a schematic diagram of the front-end bridging fault-tolerant routing process based on method name standardization and mapping table degradation. The diagram is labeled as follows: 101 - Receive front-end method name, 102 - Triple standardization processing, 103 - Precise lookup in the method registry, 104 - Degradation mapping table lookup, 105 - Dispatch call and output structured response. Figure 2 This is a diagram of a three-layer routing decision tree. The diagram is labeled as follows: 201 - first layer exact match, 202 - second layer normalized match (degradation table lookup with hyphen variants and underscore reduction), 203 - third layer recursive reduction match (continuous underscore recursive reduction), 204 - final routing result (direct dispatch / degradation dispatch / recursive reduction dispatch / error response). Figure 2 It shows the complete picture of the four-branch decision from the original method name to the final routing result. Detailed Implementation like Figure 1 As shown below, this method will be explained using a complete front-end-back-end interaction scenario that includes three cases: normal call, coded variant call, and parameter exception. The control console of a family emotional companion humanoid robot calls front-end and back-end methods through a front-end bridging communication mechanism. (a) Backend initialization When the console starts, it performs method registration and degradation mapping table construction. Business methods are registered in the method registry with their standardized names, the standardization rule being to convert method names to all lowercase. Register a login verification method named submit_login_login_1. This method accepts two parameters: username and password. Inside the function, it checks that the username is at least 3 characters long. If the verification passes, it returns an authentication result containing the token and username. If the verification fails, it throws a parameter value error exception. The method registry is then traversed to construct a degradation mapping table: for each normalized method name, a hyphen variant key is generated (replacing all underscores with hyphens), and a continuous underscore reduction variant key is generated (reducing multiple consecutive underscores to a single underscore). Each variant key is then mapped back to the original normalized method name. Once the degradation mapping table is constructed, it automatically contains mapping entries from submit-login-login-1 to submit_login_login_1. (ii) Normal front-end call scenario Front-end code execution call (e.g.) Figure 1 As shown in mark 101, call the submit_login_login_1 method in the standard format with underscores, passing in the username and password. The bridging component passes the method name in the same form as the registered name (no encoding conversion was triggered in this round). Router processing flow (e.g.) Figure 1 (As shown in mark 102, normalized) (1) Receive the original method name submit_login_login_1.

[0004] (2) Perform triple standardization: remove whitespace (no whitespace) → lowercase (all lowercase) → replace hyphens (no hyphens) → the standardization result is submit_login_login_1.

[0005] (3) Registry search (e.g.) Figure 1 (As shown in mark 103): The method searches the registry for submit_login_login_1, finds it, and obtains the corresponding processing function.

[0006] (4) Call the processing function. If the authentication is successful, return the authentication result containing the token and username.

[0007] (5) Dispatch and serialize the response (e.g.) Figure 1 (As shown in mark 105): The success flag is true, and the data field contains the authentication result. The front-end parses the response, and if successful, it redirects to the main control panel. (iii) Encoding variant calling scenarios Front-end code execution call (e.g.) Figure 1 As shown in mark 101, the developer wrote a method name containing hyphens in the front end: submit-login-login-1. The bridging component converts hyphens into underscores in the encoding path before passing it to the backend. Router processing flow: (1) Receive the original method name submit_login_login_1 (which has been bridged and converted).

[0008] (2) After standardization, it is still submit_login_login_1.

[0009] (3) Method registry hit. Another scenario—the front-end uses underscores, and the bridging encoding uses hyphens: (1) Receive the original method name submit-login-login-1.

[0010] (2) Standardization process: Hyphen replacement → submit_login_login_1.

[0011] (3) Method registry hit. Regardless of which direction the bridging encoding path is converted in, the result after standardization is consistent, and the routing is successful. (iv) Downgraded mapping scenario The front end called an old method name, Submit_Login___Login_1, which contained uppercase letters and multiple consecutive underscores from the historical code. Router processing flow: (1) Receive the original method name Submit_Login___Login_1 (the bridge does not perform encoding conversion and passes it directly).

[0012] (2) Standardization process: Remove whitespace → Lowercase → submit_login___login_1 → Hyphen replacement (without hyphen). The standardization result is submit_login___login_1.

[0013] (3) Registry search (e.g.) Figure 1 (As shown in mark 103): The method searches the registry for submit_login___login_1, but it is not found (the registry key is submit_login_login_1, which only has two underscores).

[0014] (4) Degradation mapping lookup (e.g.) Figure 1 (As shown in mark 104): Degradation mapping table lookup submit_login___login_1 — Since a recursive reduction variant with consecutive underscores was generated during initialization, the degradation mapping table contains a mapping entry from this key to submit_login_login_1.

[0015] (5) If the downgraded mapping is hit, take the original normalized name submit_login_login_1.

[0016] (6) The method registry was searched for with the name submit_login_login_1 and a match was found. The call was successful. (v) Scenarios with abnormal parameters The front end passed a username that was too short (e.g.) Figure 1 As shown in mark 101, the submit_login_login_1 method is called. Router processing flow: (1) The method name route is hit normally (e.g.) Figure 1 As shown in mark 103, the registry lookup was successful.

[0017] (2) Call the processing function. The function checks the username length and if it does not meet the requirements, it throws an exception for incorrect parameter value.

[0018] (3) The router captures an anomaly and outputs it via structured response serialization (e.g., Figure 1 (As shown in mark 105): The success flag is false, the error message contains an exception description, and the exception type field is the type name of the exception.

[0019] (4) When the front end receives the response, it determines that the success flag is false, reads the exception type field, enters the corresponding parameter error handling branch, and displays a red error message below the username input box of the front end login form. The entire interaction process, from the user clicking the login button to the front end displaying the verification error message, takes a very short time (including bridging cross-process communication delays, method execution, structured response serialization, and front-end interface responsive updates). like Figure 2 As shown, the three-layer route lookup of this method constitutes a complete decision tree from the method name input to the final route result. The first layer is exact matching (such as...). Figure 2 The most efficient path (marked by 201) is as follows: after the method name is standardized, if it is directly matched in the method registry, the call is dispatched immediately (e.g., ...). Figure 2 (As shown in the middle marked "direct dispatch"), scenarios (I) to (III) above all follow this path. Second-level standardized matching (such as...) Figure 2 (As shown in mark 202) Handling registry misses: Search the downgrade mapping table sequentially for hyphen variant keys and underscore reduced variant keys. If a match is found, return to the registry to precisely search for and dispatch the target using its normalized name (e.g., ...). Figure 2 (As indicated by the "demotion dispatch" marker). The third level of recursive reduction matching (e.g., ...) Figure 2 (As shown in mark 203) To handle deep variants that are not found in the first two layers: Perform recursive reduction of consecutive underscores on the normalized method name, successively reducing multiple consecutive underscores to a single underscore, and then look up the downgrade mapping table again. The above scenario (IV) follows this path (e.g. Figure 2(As indicated by the "Recursive Reduction Dispatch" marker). If all three levels of lookup fail, output a structured error response (e.g., ...). Figure 2 (As shown in the middle marked "Error Response"). Final routing results (e.g.) Figure 2 (As shown in mark 204) It covers four possible outputs: direct dispatch, degraded dispatch, recursive reduction dispatch, and method not found error. The front end can uniformly judge the branch based on the success flag to process all responses. It should be noted that the specific parameter values, platform interface names, and system component names in the above embodiments are merely illustrative examples. Those skilled in the art will understand that adjustments can be made in actual deployments based on specific application scenarios and platform environments, but the core technical solutions of the present invention are not limited to the specific examples described above. The above description is merely a typical implementation scenario of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A fault-tolerant routing method for a desktop application front-end bridging layer, comprising at least the following steps: Step 1: Receive the bridge method name string passed from the front-end call chain to the back-end by the front-end bridging communication mechanism. This string has an encoding variant that is inconsistent with the registered method name due to cross-language character encoding conversion. Step 2: Perform normalization processing on the method name string received in Step 1: remove whitespace characters, convert uppercase letters to lowercase letters, and replace hyphens with underscores to obtain the normalized method name; Step 3: Perform an exact lookup in the method registry using the standardized method name as the key and the callable object as the value; Step 4: If no match is found in Step 3, search for the mapping target of the standardized method name in the degradation mapping table. The degradation mapping table is automatically constructed by traversing the method registry through reflection during system initialization. For each registered method in the method registry, a degradation mapping entry containing a hyphen variant key and an underscore reduction variant key is generated. Each degradation mapping entry is mapped back to the corresponding standardized method name. Step 5: Dispatch the call request to the processing function found in Step 3 or Step 4 and execute it, capturing any exceptions during the execution process; Step 6: Serialize the execution result or exception into a structured response. When the call is successful, the structured response includes a success flag of "true" and a data field. When the call fails, the structured response includes a success flag of "false", an error message string, and an exception type name field.

2. The method according to claim 1, characterized in that, The standardization process reduces multiple consecutive underscores to a single underscore to eliminate routing failures caused by extra underscores in front-end method names.

3. A front-end bridging fault-tolerant routing system based on method name standardization and mapping table degradation, comprising: The method name receiving module is used to receive the method name string passed in from the front end. The standardization module is used to perform standardization processing on the method name string, including removing whitespace characters, converting to lowercase, and replacing underscores with hyphens. The registry lookup module is used to perform precise searches in the method registry using the standardized method name as the key. The downgrade mapping module is used to look up the mapping target in the downgrade mapping table when the registry is not found. The dispatch module is invoked to dispatch requests to the target handling function and catch execution exceptions; The response serialization module is used to serialize execution results or exceptions into structured responses.

4. A console device comprising a processor and a memory, the memory storing a computer program, wherein the processor executes the computer program to implement the steps of the method of any one of claims 1 to 2.

5. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 2.

6. The system according to claim 3, characterized in that, The degradation mapping module automatically constructs a degradation mapping table by traversing the method registry through reflection when the system starts. When a new registered method is added, the degradation mapping table is automatically updated synchronously, without the need for manual maintenance of the mapping file.

Images