fix(doors): investigate doors reported opening twice #198

New issue

Open

opened 2026-10-01 19:30:59 +00:00 by gabogg · 0 comments

gabogg commented

2026-10-01 19:30:59 +00:00

Owner

Reported symptom

Some doors appear to report an opening twice. The affected door IDs, timestamps, and whether the duplicate appears in HikCentral, this app's activity log, transition history, or live UI still need to be captured. Investigate before choosing a deduplication rule; two genuine openings must remain distinct.

Reported sequence (second-hand, not yet verified)

When someone opens a door, the system reports an opening and a closing and identifies the person who passed the card. Immediately afterward, the door reports open again and does not promptly report another close. Capture the actual event IDs and times before assuming these are duplicate events or a real second opening.

The first question is where this sequence begins: does HikCentral itself send/show the second OPEN, or does our polling, reconciliation, persistence, or UI create it from otherwise correct HikCentral data?

Investigation

Capture one affected door ID and the OPEN → CLOSE (with cardholder) → immediate OPEN sequence, including a redacted screenshot, source event IDs, and timestamps if available. Record whether the final OPEN later closes.
Compare HikCentral's own event history and live door-state response for that door with the raw webhook payloads and Artemis poll responses at the same times. Determine whether HikCentral sends the second OPEN or whether the app first introduces it. Account for any difference between the event stream and acsDoorList state.
Trace the same occurrence through local door transition persistence, access-cycle aggregation, WebSocket broadcasts, and frontend rendering. Compare source event IDs, event times, ingestion times, and physical state changes.
Check whether webhook and polling paths both create an opening, a callback is retried, a stale status poll reopens a recently closed door, or one event is rendered twice. Treat these as hypotheses until a concrete trace identifies the source.
Add a regression test at the seam that reproduces the confirmed duplication. Define event identity and ordering so retries collapse while separate physical openings do not.

Ready-to-spec outcome

One reproducible example, evidence assigning the second OPEN to HikCentral or this app, the responsible path, the intended deduplication/transition rule, and a test that fails on the duplicate but preserves distinct openings.

Related: #196 investigates stale Open Longest states and poll/webhook ordering. This issue concerns duplicate opening reports and should be triaged independently unless the same cause is demonstrated.

## Reported symptom Some doors appear to report an opening twice. The affected door IDs, timestamps, and whether the duplicate appears in HikCentral, this app's activity log, transition history, or live UI still need to be captured. Investigate before choosing a deduplication rule; two genuine openings must remain distinct. ## Reported sequence (second-hand, not yet verified) When someone opens a door, the system reports an opening and a closing and identifies the person who passed the card. Immediately afterward, the door reports **open again** and does not promptly report another close. Capture the actual event IDs and times before assuming these are duplicate events or a real second opening. The first question is where this sequence begins: does HikCentral itself send/show the second OPEN, or does our polling, reconciliation, persistence, or UI create it from otherwise correct HikCentral data? ## Investigation 1. Capture one affected door ID and the OPEN → CLOSE (with cardholder) → immediate OPEN sequence, including a redacted screenshot, source event IDs, and timestamps if available. Record whether the final OPEN later closes. 2. Compare HikCentral's own event history and live door-state response for that door with the raw webhook payloads and Artemis poll responses at the same times. Determine whether HikCentral sends the second OPEN or whether the app first introduces it. Account for any difference between the event stream and `acsDoorList` state. 3. Trace the same occurrence through local door transition persistence, access-cycle aggregation, WebSocket broadcasts, and frontend rendering. Compare source event IDs, event times, ingestion times, and physical state changes. 4. Check whether webhook and polling paths both create an opening, a callback is retried, a stale status poll reopens a recently closed door, or one event is rendered twice. Treat these as hypotheses until a concrete trace identifies the source. 5. Add a regression test at the seam that reproduces the confirmed duplication. Define event identity and ordering so retries collapse while separate physical openings do not. ## Ready-to-spec outcome One reproducible example, evidence assigning the second OPEN to HikCentral or this app, the responsible path, the intended deduplication/transition rule, and a test that fails on the duplicate but preserves distinct openings. Related: #196 investigates stale Open Longest states and poll/webhook ordering. This issue concerns duplicate opening reports and should be triaged independently unless the same cause is demonstrated.

gabogg added the

needs-triage

label

2026-10-01 19:30:59 +00:00