# Return the right state-change result from Service Fabric data-loss recovery

> What should a Service Fabric OnDataLossAsync implementation return after examining or restoring surviving state?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:31:41+00:00
- Modified: 2026-09-10T00:32:00+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

What should a Service Fabric OnDataLossAsync implementation return after examining or restoring surviving state?

## Potentially affected

Custom stateful Service Fabric services implementing OnDataLossAsync recovery handling.

## DSE recommendation

DSE recommends making the handler's return value an explicit state-change contract.

## Article

## Source facts

Service Fabric calls OnDataLossAsync for suspected, not necessarily proven, data loss and chooses the remaining replica with the most progress. After examination and any restoration, the handler returns true if it changed state and false if it did not. A true result causes other remaining replicas to be dropped and rebuilt from that replica; false lets them retain their state. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery).

## Applicability

Use this review for application-owned recovery code, not as permission to force system services out of quorum loss. Establish how the implementation decides whether state changed. Keep the decision to restore a backup separate from the meaning of the Boolean result.

## DSE recommendation

DSE recommends making the handler’s return value an explicit state-change contract. Have the service owner review the paths for no change, successful restoration and incomplete investigation. Define how coordinated services will be checked before recovery is accepted, and preserve enough evidence to explain which state was selected. Do not return a success-looking value merely because the handler reached its final line.

## Verification

In a disposable failure simulation, exercise both an unchanged surviving replica and a path that actually modifies state. Inspect the returned value and resulting handling of the remaining replicas. Verify application data and cross-service consistency after the test, not just replica availability. Record why the handler concluded that a change did or did not occur before approving the implementation.

## Official references

[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery). Source retrieved September 9, 2026.

## Primary reference

- Name: Azure Service Fabric disaster recovery - Azure Service Fabric | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Return the right state-change result from Service Fabric data-loss recovery,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.