Skip to content

first_occurred is reset when a fault re-occurs, so it does not name the first occurrence #672

Description

@bburda

Summary

When a FAILED event reactivates a CLEARED fault, the fault manager overwrites first_occurred with the new timestamp while occurrence_count keeps climbing. Both backends do it on purpose: src/ros2_medkit_fault_manager/src/sqlite_fault_storage.cpp:729-735 and src/fault_storage.cpp:172-175 at 8b1969f ("this is a new outage cycle, not a continuation of the one that just cleared"), pinned by test_fault_manager.cpp:424 and test_sqlite_storage.cpp:503.

A jam alarm asserted at 18:54:39.059Z, cleared on the controller, asserted again at 18:54:54.925Z:

"occurrence_count": 2,
"first_occurrence": "2026-09-08T18:54:54.925Z",
"last_occurrence": "2026-09-08T18:54:54.925Z"

faults.db holds one row per code, so the first time is gone from the fault store. The audit log keeps it, but it is off by default and no REST route reads it. A UI that labels the value "First occurrence" reads the API correctly and shows the wrong thing.

#618 documented this at the message layer. Fault.msg and docs/api/messages.rst say "timestamp when the current occurrence started". The name still says first, and docs/api/rest.rst shows extended_data_records.first_occurrence and first_occurred only as example values, with no definition.

Proposed solution

  1. Keep first_occurred at the first occurrence for the life of the code, let last_occurred and occurrence_count carry the history, and add cycle_started for the current outage's start. Additive.
  2. Keep today's behaviour and rename the reset field to cycle_started. Breaking on /api/v1/faults, on the SOVD extended_data_records block and on Fault.msg.

Either way docs/api/rest.rst needs the definition messages.rst already has. A PR for that part follows. The naming choice stays open here.

Additional context

Reproduces through the services alone: report_fault (FAILED), clear_fault, report_fault again, and first_occurred moves to the second report with occurrence_count 2. A FAILED re-report while the fault is still CONFIRMED leaves first_occurred and the count alone and only moves last_occurred, so the reset is tied to the CLEARED to FAILED edge. Seen on main at f873448 (0.6.0), unchanged at 0.7.0 (8b1969f). ROS 2 Jazzy, Ubuntu 24.04.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions