Status of an RFC at the Document Search page does now show information which RFCs this RFC obsoletes and updates

[smyslov]

Describe the issue

The results shown on the Document Search page (after user searched for some RFCs) include the Status column. The status information for each RFC includes "Updated by", "Obsoleted by" information, but for some reason does not include "Obsoletes" and "Updates" information. Note, that on the Document Status page all meta-data is correctly shown, it is only missing on the Document Search page.

My recollections tell me that this information was present before, I'm puzzled why it was removed, thus I consider this is a bug. If it was removed deliberately, then I'm not sure this is a good move.

An example URL:
https://datatracker.ietf.org/doc/search?name=2821&sort=&rfcs=on&activedrafts=on&by=group&group=

For RFC 2821 it is correctly shown that it is obsoleted by RFC 5321, but for RFC 5321 it is not shown that it obsoletes RFC 2821.

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[rjsparks]

This is a consequence of the move to rfcs as first-class objects rather than being versions of drafts, and a long-running error in ingesting rfc information when syncing with the rfc-editor queue (not trivial to fix in the current architecture since the datatracker (badly) creates the rfc Document object without the file content being present - that appears magically as far as the datatracker is concerned as a periodic rsync places the files underneath it.

The work we are in the middle of, modernizing the rpc tooling, will change this architecture, and the content of the rfc will be posted to the datatracker as rfcs are published, making it possible to mine them for references at that time. We expect this to be in production before IETF 125.

I have been looking (and will continue to look) at what can be done to repair the reference information in the existing architecture before then.

[rjsparks]

fwiw, back when the datatracker modeled rfcs as versions of drafts, the references were also incorrect - they were just copied from references extracted from the last version of the draft instead of being recomputed from the rfc text.

[rjsparks]

See also #10015, #8964, #8900, #5582, #5093, and even #3871 (though the last had a different root cause).

[rjsparks]

Ah - I was too focused on the references problem and too quick to jump there. Sorry for the noise, but it's important noise.

What's actually reported probably has an easier fix - my first guess is there's a place in the search results template that is assuming 'draft' when it should be looking at the document type. We will investigate.