| Previous | Next |
| PEER_E_INVALID_CLASSIFIER_PROPERTY | PEER_E_INVALID_CREDENTIAL_INFO |
PEER_E_INVALID_RECORD_EXPIRATION
Where the peer stack rejects the operation
PEER_E_INVALID_RECORD_EXPIRATION — HRESULT 0x80632080 marks the expiration value on a peer record is not a valid lifetime for record storage and replication. Treat it as a record contract result rather than a generic peer-networking failure.
Peer records combine a typed record structure, optional searchable XML attributes, payload data, creator metadata and expiration. The local database may receive records in an order different from application dependencies.
Evidence to preserve before retrying
- Record the first failing surface among PEER_RECORD.ftExpiration, PeerGroupAddRecord and peer-time conversion functions.
- Preserve expiration FILETIME, creation time, peer time conversion, record flags, graph/group clock state and serializer representation.
- Place successful creation or discovery, state-changing events and the failing call on one timeline.
- Keep peer names, identities, record identifiers, invitation data and endpoints in their original Unicode or binary representation.
Controlled isolation
Add the same record with a documented future expiration and then reapply the original timestamp conversion. Change one variable only; simultaneous changes to identity, cloud, database and firewall state destroy attribution.
| Checkpoint | Question for this HRESULT |
|---|---|
| Before the API | Was the required local replicated store obtained in this process and user context? |
| At the HRESULT | Preserve expiration FILETIME, creation time, peer time conversion, record flags, graph/group clock state and serializer representation. |
| After correction | normalize timestamps, use the peer API time-conversion functions where required and keep expiration later than creation. |
Neighboring result
PEER_E_INVALID_TIME_PERIOD differs because record expiration belongs to replicated data; invalid-time-period belongs to invitation or credential validity. Keep both HRESULT values in chronological order because a corrected prerequisite can expose the next validation stage.
Safe response
Normalize timestamps, use the peer API time-conversion functions where required and keep expiration later than creation. Preserve durable graph databases, group exports, identity certificates and invitation artifacts before changing them.
References
- Microsoft: Record attribute schema — it uses this source for the documented peer boundary.
- Microsoft: Record search query format
- Microsoft: Record dependencies
- Microsoft: Grouping API functions
Looking for a different code? Search another status or error code.