cFS: update sample_app submodule with improved error handling

[rajv79]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.

Describe the contribution
This contribution improves defensive error handling and operational visibility in the Sample App ground command processing logic.
Table access failure paths in SAMPLE_APP_ProcessCmd are now explicit, with errors reported via Event Services, error counters incremented, and clean early returns on failure.

Testing performed
Steps taken to test the contribution:

1. Built the Sample App using the standard cFS build configuration.
2. Verified nominal command execution is unchanged.
3. Verified table access failures generate error events and increment error counters

Expected behavior changes

1. API Change: None
2. Behavior Change: Improved visibility and consistency in table access failure handling.
3. Impact: Low risk, defensive improvement only

System(s) tested on
-Hardware: PC
-OS: Windows (development environment)
-Versions: cFS Sample App (current main branch)

Additional context
This change follows standard cFS practices by improving robustness without altering functional behavior. The scope is intentionally small to support safe review and integration.

Code contributions
The cFS repository is provided to bundle the cFS Framework. It is utilized for bundling submodules, continuous integration testing, and version management and does not contain any software. Code contributions should be directed to the appropriate submodule.

**Contributor Info -

• Full name: Vivek Raj
• Organization: Personal
• Contributor type: Individual
  -CLA: Individual CLA will be completed and submitted as required

[rajv79]

@thesamprice @ivanperez-keera @egyptiankarim @classmember

Hi everyone,
I’ve pushed the changes addressing defensive error handling in the sample_app submodule.
The cFS-Framework and cFS_APP_Individual Individual CLA has been signed and emailed to cfs-program@lists.nasa.gov and GSFC-SoftwareRelease@mail.nasa.gov

GitHub username: rajv79.

Please let me know if any additional changes, information, or follow-ups are needed. Happy to address feedback.

Thank you for your time and review

[ivanperez-keera]

Hi,

My two cents:

• It may help if you create an issue documenting what the problem is and tie the commit to the issue. If one already exists, then it'll help if you mention it in the commit message.

• If I understand it correctly, the core idea is that, every time there is an error, you are:

  1. Increasing the error counter.
  2. Sending out an event with:
     CFE_EVS_SendEvent(SAMPLE_APP_CMD_ERR_EID, CFE_EVS_EventType_ERROR, ...)

  Is there a particular reason why you also changed the structure of the function to return early in case of error, rather than having just one return statement for the whole function?

[rajv79]

Hi,

My two cents:

• It may help if you create an issue documenting what the problem is and tie the commit to the issue. If one already exists, then it'll help if you mention it in the commit message.

• If I understand it correctly, the core idea is that, every time there is an error, you are:

  1. Increasing the error counter.
  2. Sending out an event with:
     CFE_EVS_SendEvent(SAMPLE_APP_CMD_ERR_EID, CFE_EVS_EventType_ERROR, ...)

  Is there a particular reason why you also changed the structure of the function to return early in case of error, rather than having just one return statement for the whole function?

Hi, thank you for the feedback. I appreciate it.

Regarding the issue tracking, there is currently no existing issue that specifically documents this behavior. I agree that creating an issue to describe the problem and tie the change to it formally would be helpful. I’m happy to open an issue and reference it in the commit message if that is preferred.

On the implementation details:

This change is intended to make error handling more explicit and defensive. Returning early on failure allows the function to separate error paths from the nominal execution path clearly, avoid using invalid table state, and reduce nested control flow. This pattern also makes it immediately clear that no further processing should occur once a table access or release failure is detected.

The functional behavior remains unchanged in the success case, and the early returns are only taken on error paths where continued execution would not be meaningful. That said, if maintaining a single return point is preferred for consistency with existing cFS style, I’m happy to refactor the function accordingly.