Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-629

Eliminate the requirement that error codes be globally unique

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: T&S
    • Labels:
      None

      Description

      I propose to eliminate the T&S requirement that error codes (the numeric value of the errorCode topic) be globally unique. I feel this requirement is unnecessary and disruptive.

      • It is unnecessary because the errorCode topic is distinct for each CSC. There is no possibility of confusing an errorCode sample from one CSC with that from another because part of the DDS topic name is the SAL component name (e.g. "M1M3").
      • There are cases where it would be useful to have a few standard error codes shared among several CSCs. For instance in ts_salobj what happens if a CSC fails to transition to a desired summary state? Ideally the CSC-specific code will itself go to the fault state with a specific error code. But if it fails to do that, I think the best fallback is to allow the base class to go into a fault state with a more generic error code. I don't see how to do this sensibly unless error codes can be shared.
      • It is a waste of time to manage the allowed globally distinct ranges of error codes for CSCs. Even getting a range for a new CSC is a headache. It will be far worse if we run out of error codes for a CSC and have to shift ranges or assign discontiguous ranges for a given CSC. We don't have time for this.

        Attachments

          Issue Links

            Activity

            Hide
            mareuter Michael Reuter added a comment -

            It should be section 2.3.1.1.1.1.1 of LTS-441 since there is more to that document then error codes.

            Show
            mareuter Michael Reuter added a comment - It should be section 2.3.1.1.1.1.1 of LTS-441 since there is more to that document then error codes.
            Hide
            rowen Russell Owen added a comment -

            The RFC has been accepted. It will be marked implemented when the appropriate document has been written and adopted.

            Show
            rowen Russell Owen added a comment - The RFC has been accepted. It will be marked implemented when the appropriate document has been written and adopted.
            Hide
            rowen Russell Owen added a comment -
            Show
            rowen Russell Owen added a comment - I have filed the LCR: https://project.lsst.org/groups/ccb/node/3691
            Hide
            rowen Russell Owen added a comment -

            The CCB only allowed deprecating LSE-399 (and is now voting on that). The other changes are T&S responsibility. Here are my suggested changes:

            Declare section 2.3.1.1.1.1.1 of LTS-441 obsolete. (This was accepted in the RFC).

            In addition I propose that we declare 2.3.1.1.1.1 of LTS-441 obsolete. This section demands that any CSC maintain a file listing error codes and associated text. This seems entirely unnecessary because the errorCode SAL/DDS message already contains that information. It has 3 fields:

            • errorCode a numeric code
            • errorReport, a string describing the error
            • traceback, an optional traceback.
              I would argue that the first two fields are fully adequate to cover the fundamental requirement that users can understand an error code when it occurs. In addition code is certainly going to set the errorReport field, and it duplicates information to have to put the same text in a separate file. It will be very difficult to keep such a file (or files) synchronized to the code.

            Instead consder changing 2.3.1.1.1 Publish Error Code to say:

            When a fault occurs for a component, the component shall publish an appropriate error code and text description of the error to the component errorCode topic.

            Show
            rowen Russell Owen added a comment - The CCB only allowed deprecating LSE-399 (and is now voting on that). The other changes are T&S responsibility. Here are my suggested changes: Declare section 2.3.1.1.1.1.1 of LTS-441 obsolete. (This was accepted in the RFC). In addition I propose that we declare 2.3.1.1.1.1 of LTS-441 obsolete. This section demands that any CSC maintain a file listing error codes and associated text. This seems entirely unnecessary because the errorCode SAL/DDS message already contains that information. It has 3 fields: errorCode a numeric code errorReport, a string describing the error traceback, an optional traceback. I would argue that the first two fields are fully adequate to cover the fundamental requirement that users can understand an error code when it occurs. In addition code is certainly going to set the errorReport field, and it duplicates information to have to put the same text in a separate file. It will be very difficult to keep such a file (or files) synchronized to the code. Instead consder changing 2.3.1.1.1 Publish Error Code to say: When a fault occurs for a component, the component shall publish an appropriate error code and text description of the error to the component errorCode topic.
            Hide
            rowen Russell Owen added a comment -

            The CCB has accepted LSE-399.

            Show
            rowen Russell Owen added a comment - The CCB has accepted LSE-399.

              People

              • Assignee:
                rowen Russell Owen
                Reporter:
                rowen Russell Owen
                Watchers:
                John Parejko, Michael Reuter, Russell Owen, Steve Pietrowicz
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End: