Re-resolve Service Fabric endpoints after the listener rejects a stale identity

Source facts

Service Fabric’s ASP.NET Core integration middleware adds a unique identifier to the registered service address and checks it on requests. A mismatch returns HTTP 410 Gone. Clients should then resolve the service endpoint again. This cooperative protection is intended for a trusted environment; it does not authenticate a service securely against a hostile tenant. Microsoft Learn.

Applicability

Focus this review on internal clients caching dynamically assigned endpoints. Distinguish an address that is reachable from an address that still represents the intended service. Do not extend this mechanism into a claim that tenant authentication, authorization or transport security has been established.

DSE recommendation

DSE recommends checking the listener’s identity validation and the client’s endpoint refresh behavior together. Have the application owner trace where a resolved address is cached and what happens after an identity rejection. Keep this error path separate from ordinary application failures: the proposed response is to refresh the destination, not repeatedly submit the same request to an unchanged cached address.

Verification

In an isolated integration test, exercise a stale endpoint and inspect the listener response. Confirm that the client performs a fresh resolution after the documented rejection and subsequently addresses the intended service. Retain the old and refreshed endpoint identities without collecting sensitive request payloads. Test the application’s separate authentication controls through their own acceptance criteria; passing this routing test is not a substitute.

Official references

Microsoft Learn. Source retrieved September 9, 2026.