A resolver rollback can restore the intended target in the registry while some users still reach the wrong landing page. Registry state, resolver caches, intermediary caches and local clients do not necessarily converge at the same instant.
This guide explains how to reconcile those layers after rollback, collect cache-expiry evidence without guessing, and close an identifier incident only after independent tests show that the right remote-sensing product identity is being served.
Examples use fictional identifiers and deployments. Repository operators must follow their registry, preservation, security and incident policies. Do not purge or manipulate third-party caches without authority.
eduKateSG · The Gold Standard · Remote Sensing
Find your next learning step
Trace one identifier from the rollback transaction through registry readback, resolver paths, cache evidence, landing-page identity and closure.
- ROUTE 1 · Define the rollback state — name the target, interval and affected identity
- ROUTE 2 · Reconcile layers — compare registry, resolver and landing page
- ROUTE 3 · Test caches — use freshness and validation evidence
- ROUTE 4 · Close the incident — require independent and repeated checks
- ROUTE 5 · Transfer carefully — limits, FAQs and connected sources
Full chapter index · Remote Sensing root guide · Learning that transfers into life · How X Works hub
Chapter contents
Chapters 1–3
Chapters 4–5
Chapters 6–8
Chapters 9–10
CHAPTER 1 OF 12
1. Rollback ends a change, not the incident
A rollback is a new registry update that restores a previously approved target. Record the identifier, failed target, restored target, transaction time, operator, reason and configuration versions. Preserve the failed promotion rather than editing it out of history.
The preceding guide on resolver-configuration promotion, registry audit trails and rollback explains the transition. Post-rollback work asks what each external layer now serves.
CHAPTER 2 OF 12
2. Define the affected interval and identity test
The affected interval begins when the wrong target could have resolved and ends only when closure tests pass, not merely when the rollback command succeeds. Estimate earliest and latest times from registry activities, monitoring and cache evidence, and label uncertainty.
Define the landing-page identity fields: collection identifier, product version, sensor, processing level, time span and access route. HTTP 200 is not enough; a healthy page for another collection remains an incident.
CHAPTER 3 OF 12
3. Reconcile three authoritative views
Compare local desired configuration, the registry API record and the public resolver result. The local file states intent, the registry states the registered target, and public resolution states what a request path receives. Agreement provides stronger evidence than any one view.
DataCite notes that DOI landing-page URLs can be updated and that the record exposes URL and metadata version. A last-updated timestamp may also change through internal re-indexing, so use field values and activity evidence rather than timestamp meaning alone.
CHAPTER 4 OF 12
4. Worked example: registry fixed, one path stale
At 10:00 UTC a fictional DOI is rolled back from /collection-v5 to /collection-v4. At 10:05 the registry API shows v4. A clean resolver request from Region A reaches v4, while Region B still reaches v5 with Age: 1,500 seconds and max-age=3,600.
The evidence supports a cached response on the Region B path, not a failed registry rollback. Closure should wait for expiry or successful validation and a repeated identity check. Resubmitting the rollback could add confusion without changing that cache.
| Time and layer | Observed state | Interpretation |
|---|---|---|
| 10:05 registry API | Target v4 | Rollback recorded |
| 10:06 Region A | Final page v4 | One path converged |
| 10:07 Region B | v5, Age 1500 | Fresh cached response possible |
| 11:10 Region B | v4 after validation | Path converged; repeat test |
CHAPTER 5 OF 12
5. Read cache headers as evidence, not promises
RFC 9111 defines freshness through freshness lifetime and current age. Cache-Control max-age or s-maxage and Expires can set explicit freshness; Age estimates time since generation or validation along cache paths. Missing explicit freshness can permit heuristic caching in some cases.
A TTL is therefore not a universal countdown visible to every cache. Cache keys, Vary, shared versus private directives, validation and local browser history can change what is served. Record the actual response headers and request conditions.
CHAPTER 6 OF 12
6. Distinguish expiry, validation and invalidation
Expiry makes a stored response stale; it does not necessarily delete it. A stale response may be revalidated using validators such as ETag or Last-Modified. Invalidation marks stored content unusable through a defined mechanism. These events are different and need different evidence.
If a response changes after conditional validation, keep the request and response headers. If it changes only after a cache purge, record who authorised the purge, its scope and the following test. Do not infer a global purge from one successful path.
CHAPTER 7 OF 12
7. Test multiple paths without manufacturing independence
Use distinct networks, regions or resolver services where permitted, and avoid reusing the same proxy. But two tools may share infrastructure, so document the path rather than calling it independent by name alone.
Include a normal browser-style request, a header-capturing client and a content-negotiation request when relevant. DataCite content negotiation can return metadata representations, while text/html resolution normally redirects to the landing page; the two paths answer related but different questions.
CHAPTER 8 OF 12
8. An evidence matrix prevents premature closure
For each path, record time, final URL, redirect chain, status, cache headers, validators and landing-page identity. Repeat after the expected freshness window and after any validation event. A matrix exposes whether only one convenient path has recovered.
The compact form below separates registry correctness from user-visible correctness. Add more regions or clients according to actual risk and reach.
| Layer | Test | Closure evidence |
|---|---|---|
| Registry | Read target and metadata version | Restored value persists |
| Resolver | Capture full redirect chain | Approved final URL on sampled paths |
| Cache | Inspect Age, freshness and validators | Old representation stale or replaced |
| Landing page | Check resource identity fields | Correct product and version displayed |
CHAPTER 9 OF 12
9. Set incident-closure tests before declaring success
Closure can require persistent registry agreement, correct resolution on declared paths, correct landing-page identity, no recurrence across a defined observation window, completed impact review and an owner sign-off. Specify any residual untested paths.
A green dashboard is supporting evidence, not the closure decision. Save the raw observations or durable summaries needed to reconstruct what passed and when.
CHAPTER 10 OF 12
10. Review users and derivatives affected by the interval
Wrong resolution may have led users to download a different product version, cite the wrong page or cache metadata downstream. Review access logs, support reports and known harvesters where lawful and proportionate. Notify affected users when policy and impact require it.
Do not claim that every user saw the wrong target merely because it was registered. Likewise, do not claim no impact because monitoring saw one correct path. Describe observed, possible and ruled-out effects separately.
CHAPTER 11 OF 12
11. Limits, misconceptions and changed-context transfer
A registry readback cannot prove every cache has converged, and a correct resolver response cannot prove the registry audit trail is complete. Persistent identification depends on stewardship across both identity and delivery layers.
Transfer check: move from a DOI redirect to an API metadata endpoint behind a CDN. The same reconciliation logic applies, but cache keys, content negotiation, authentication and invalidation controls differ. Re-establish the layers and closure tests instead of copying one TTL.
Should a rollback be repeated when one region still resolves to the old page?
Not automatically. First compare registry state and cache evidence. If the registry is correct and the response is a fresh cached representation, repeating the update may not help and can obscure the audit trail.
When can the incident close?
When predeclared registry, resolver, cache, landing-page identity and impact tests pass across the required observation window, with residual uncertainty recorded.
CHAPTER 12 OF 12
12. Evidence route and connected reading
DataCite explains landing-page URL updates, DOI record fields and metadata versions, the limits of the last-updated timestamp, and content negotiation. RFC 9111 defines HTTP cache freshness, age and validation.
Continue through citation-resolution audits, resolver-failure monitoring, identifier-target change control, and the immediate promotion and rollback guide. The Remote Sensing root connects the subject.
Contents · Previous chapter · Return to the Remote Sensing root