Data resiliency

This guide explains the DIVA Web third-party data resiliency behavior that is relevant for integrators.

Data resiliency means DIVA tries to keep playback available when a dependency fails, as long as entitlement can provide refreshed playback data or a backup endpoint.

In DIVA Web third-party video production, the implemented resiliency workflow is:

Workstream	Purpose	Integrator perspective
WS6	Retry entitlement after eligible fatal playback errors	Use when entitlement may return a refreshed token, license URL, manifest URL, or backup endpoint

Standard retry handling

Standard retry handling is the first resiliency layer. It retries the same failed request using the configured retry policy.

This includes:

Entitlement and heartbeat requests for HTTP 408 and 429
Playback/network requests for HTTP 408, including manifests, media segments, tracking URLs, and closed captions

If playback still fails after standard player/request retries are exhausted, WS6 may start for eligible fatal playback errors. WS6 is different because it sends a new entitlement request with Data.retries and may receive refreshed playback data or a backup endpoint.

How this relates to data resiliency:

Area	Category	Why
Entitlement `408` / `429` retry	Standard entitlement retry	Same entitlement request is retried using configured retry policy
Heartbeat `408` / `429` retry	Standard heartbeat retry	Same heartbeat request is retried using configured retry policy
Playback manifest `408` retry	Standard player/network retry	Player retries the same failed playback resource
Segment/chunk `408` retry	Standard player/network retry	Media engine retries the same failed media request
Tracking URL `408` retry	Standard metadata/tracking retry	Same request retry
WS6 `Data.retries`	Entitlement recovery after fatal playback error	Happens only after normal resource-level retries are exhausted and a fatal eligible player error reaches DIVA

Shared entitlement behavior

For V3 entitlement flows, the /videos tokenization call does not send Authorization. If the response body returns a SessionToken, DIVA stores it and uses it only on subsequent /videos/heartbeat requests as Authorization.

Each heartbeat response can return a new SessionToken, and DIVA replaces the stored value for the next heartbeat. If no token is returned, DIVA omits Authorization, so V2 behavior stays unchanged.

The standard entitlement and heartbeat retry handling still applies to HTTP 408 and 429 responses through the configured retry policy.

WS6: Entitlement retry after fatal playback error

WS6 handles eligible fatal playback errors before DIVA shows the final playback error. DIVA asks entitlement again for refreshed playback details, then restarts playback with the returned data.

This can help when entitlement can return:

A backup manifest URL
A refreshed DRM token
A refreshed license URL
Updated DRM headers
A healthier CDN/origin endpoint

WS6 is not a same-request network retry. Standard player/request retries happen first. WS6 starts only after the media player emits a fatal error that DIVA classifies as retryable.

WS6 configuration

{
  "settings": {
    "errorsHandling": {
      "entitlementRetriesOnPlaybackError": 3
    }
  }
}

Setting	Meaning
`0`	Disabled. This is the default.
`> 0`	Maximum number of entitlement recovery attempts.
Negative value	Normalized to `0`.

How WS6 works

DIVA starts playback normally.
The initial entitlement request does not send Data.retries.
The player performs its normal internal/request-level retries.
If the player emits an eligible fatal error, DIVA intercepts it.
DIVA hides the final UI error while recovery is in progress.
DIVA increments the recovery attempt.
DIVA sends a new entitlement request with Data.retries.
Entitlement may return the same endpoint or a backup/refreshed endpoint.
DIVA updates the current source and DRM data.
DIVA rebuilds playback.
When playback reaches PLAYING, DIVA resets the retry counter.
If attempts are exhausted, DIVA surfaces the final playback error.

Data.retries is serialized as a string in the entitlement Data payload.

Example:

Request	`Data.retries`
Initial entitlement request	Not sent
First WS6 recovery request	`"1"`
Second WS6 recovery request	`"2"`
Third WS6 recovery request	`"3"`

Retryable WS6 failures

DIVA Web retries failures that may be fixed by refreshed entitlement data or a different endpoint:

DRM player errors
HTTP 408
HTTP 500 through 599
Timeout errors
Browser network failures without a usable HTTP response, commonly status-0
Some HLS status-0 load failures represented as source/load errors

DIVA Web does not retry every player error. For example:

HDR capability errors 3015 and 3016 stay on the existing HDR fallback path.
HTTP 429 is not part of the WS6 retry behavior.
Non-retryable errors go directly to normal final error handling.
Exhausted retry attempts surface the final playback error.

V2 and V3 entitlement API versioning

V2 and V3 are entitlement API versions. They are not resiliency workstreams.

DIVA Web can pass version intent into entitlement request data. In the current implementation, when the configured entitlement version is 3 or v3, DIVA adds:

{
  "version": "3"
}

to the entitlement Data payload.

Integrator responsibility:

Confirm whether routing is handled by entitlement/backend services or by configuration.
Avoid ad-hoc URL string replacement where possible.
Prefer explicit environment/configuration-driven endpoint routing.
Validate that V2/V3 requests reach the expected entitlement contract.

Which feature should I use?

Scenario	Recommended capability
Entitlement may return a refreshed or backup endpoint after playback failure	WS6
App needs to select entitlement API version	V2/V3 configuration
App needs V3 heartbeat token rotation	V3 `SessionToken` heartbeat handling
Manual DRM-to-non-DRM operational failover	Platform/operations Business Continuity Plan (BCP) runbook, not only DIVA Web config

Validation checklist

Validate with controlled failure scenarios:

entitlementRetriesOnPlaybackError: 0 disables WS6
WS6 sends no Data.retries on the initial request
WS6 sends "1", "2", etc. during recovery
Entitlement can return a backup URL/token/license
Final error appears after retry exhaustion
HTTP 408 and 5xx behavior is confirmed
HTTP 429 is not treated as WS6 retryable
V2/V3 routing reaches the expected entitlement API
V3 /videos requests do not send Authorization
V3 heartbeat requests use the stored SessionToken as Authorization
Heartbeat token rotation is confirmed when heartbeat responses return a new SessionToken

Notes

WS5 bypass-source recovery is a Back Office workflow and does not apply to third-party video production.

Important boundaries

WS5 is source-level entitlement bypass for DRM-free BCP playback in the Deltatre video workflow.
WS5 is not generic DRM error recovery.
WS6 is entitlement retry after eligible fatal playback errors.
WS6 is not the same as normal HTTP/player resource retries.
Data.retries belongs to WS6 recovery entitlement requests.
V2/V3 is API versioning, not data resiliency.
V3 SessionToken rotation applies to heartbeat authorization handling.
WS7/WS8 should be described only as broader platform/operational capabilities unless their DIVA Web implementation and settings are confirmed.

Standard retry handling​

Shared entitlement behavior​

WS6: Entitlement retry after fatal playback error​

WS6 configuration​

How WS6 works​

Retryable WS6 failures​

V2 and V3 entitlement API versioning​

Which feature should I use?​

Validation checklist​

Notes​

Important boundaries​

Reference points​