User Story #615
openFeature #610: F3 SOS Emergency
EPIC #611: E 3.1 SOS Activation & WebRTC Connection
US-029.BE.1 — Early Release Cancellation — Backend Guarantee of No Side Effects
0%
Description
────────────────────────────────────────────────────────────
US-029.BE.1 — Early Release Cancellation — Backend Guarantee of No Side Effects
────────────────────────────────────────────────────────────
Role
As a backend developer on Ham Rahi,
I need to guarantee that the server produces absolutely no side effects
when an SOS hold is released early and no activation event reaches the
backend,
So that incomplete hold attempts leave no phantom records, no alerts,
no notifications, and no state that could mislead police panel operators
or corrupt reporting data.
User Story
As Priya,
I want to be certain that lifting my finger before 5 seconds does not
silently create any emergency record, notify anyone, or leave any trace
in the system,
So that I can press and hesitate freely without fear of triggering a
real emergency response.
In-Scope
- Confirming the backend activation endpoint is only reachable via the
explicit activation event emitted by US-029.FE.1 at the 5-second
threshold — no intermediate or partial signals reach the server
during the hold - Ensuring no SOS session record, incident draft, or alert log entry
is created for an early-release attempt - Ensuring no push notification, WebSocket message, or any other
outbound communication is dispatched toward the police panel,
third-party services, or the citizen's emergency contacts as a result
of an early-release attempt - Ensuring no WebRTC session is pre-initialised or reserved during the
hold countdown — WebRTC handshake must not begin until the activation
event is received - Idempotency verification: if a malformed or duplicate early-release
signal were somehow received by the server, the server must ignore it
and return no confirmation - Audit log must record that no activation occurred — the absence of
an SOS record for a session is itself the correct and expected state
Out-of-Scope
- Cancellation of an SOS that has already been fully activated and
confirmed server-side (post-activation rollback is a separate concern) - Rate-limiting or abuse detection for repeated false-start attempts
(Phase 2 concern) - Logging or flagging repeated early-release patterns for analytics
(Phase 2) - Any client-side state management (covered in US-029.FE.1)
Acceptance Criteria
AC1 The SOS activation endpoint does not receive any request during a
hold that ends in early release — the backend has no awareness that
a hold attempt occurred.
AC2 If a request does not arrive at the activation endpoint within the
expected window after a session is established, the backend creates
no record, issues no alert, and performs no action.
AC3 No SOS incident record, draft, or placeholder entry is written to
the database for an early-release attempt.
AC4 No push notification, SMS, or any outbound communication is
triggered on the police panel, citizen's registered emergency
contacts, or any third-party integration as a result of an
early-release attempt.
AC5 No WebRTC session negotiation (offer, answer, ICE candidates) is
initiated by the backend for a hold attempt that does not produce
an activation event.
AC6 A penetration or edge-case test that artificially sends a
malformed or partial signal to the activation endpoint without
a valid activation payload results in a rejection response (4xx)
and produces no side effects in the database or notification layer.
AC7 The backend audit log for a session that experienced an
early-release attempt contains no SOS activation entry — the
absence of the record is verifiable and is the correct expected
state confirmed by QA.
Definition of Done
- Confirmed via integration test that no DB record is created when
activation endpoint is not called - Confirmed via integration test that no outbound notification fires
without a valid activation payload - Confirmed via test that no WebRTC negotiation is triggered
server-side without activation event - Edge-case test (malformed signal) passing with 4xx and no side effects
- QA sign-off on audit log verification
- No open P1 or P2 bugs
- Code reviewed and merged
No data to display