Appellate: Got weird docket entry number

[mlissner]

I deleted all cookies, then purchased document ten from this docket:

https://www.courtlistener.com/docket/8034892/nvlsp-v-united-states/

It said it got uploaded (hell yeah!), but it didn't show up in the docket, so I went to look at the RECAP processing queue. The matching document is here:

https://www.courtlistener.com/api/rest/v3/recap/7378058/?court=cafc

Which returns:

{
    "id": 7378058,
    "court": "cafc",
    "docket": null,
    "docket_entry": null,
    "recap_document": null,
    "date_created": "2022-12-28T11:47:09.650744-08:00",
    "date_modified": "2022-12-28T11:59:10.936545-08:00",
    "pacer_case_id": "13514",
    "pacer_doc_id": "01301660046",
    "document_number": 97,
    "attachment_number": null,
    "status": 5,
    "upload_type": 3,
    "error_message": "Unable to find docket entry for item.",
    "debug": false
}

I wondered why it was "unable to find docket entry for item", and the answer is that it somehow thinks that the document number is 97. That's weird! It should be document number 10.

Back in PACER, it looks like the document number also shows as 97:

That must be getting parsed from somewhere it shouldn't be?

[ERosendo]

@mlissner It's odd but the receipt page says that the document number is 97. Here's a screenshot:

I noticed that the case number is also different. I'm trying to get document ten from case 19-1083 but the link is redirecting to document 97 from case 19-1081.

[ERosendo]

I checked the docket 19-1081 and the document is also listed there (as docket entry 97).

I reviewed the HTML of the docket entry in both docket reports and the href attribute of the anchor is the same, so I think this issue happens when the same document( with the same pacer_doc_id) is listed in two different dockets using different entry numbers.

the extension is showing this weird behavior too, so I disabled it to check how PACER handles these cases and noticed that the only difference in the receipt pages is the value populated in the caseId hidden field, for document 97 the caseId is 13514 but for document 10 the caseId is 13516

I think we can fix this issue if the extension adds the caseId parameter to the href attribute of the anchors in the docket report so the href attribute will look like the following:

https://ecf.cafc.uscourts.gov/docs1/01301660046?caseId=13514
https://ecf.cafc.uscourts.gov/docs1/01301660046?caseId=13516

Let me know what you think

[mlissner]

Hm, here are three experiments:

1. Buy the document from CL's "Buy On PACER" link.

STR:

• Go here: https://www.courtlistener.com/docket/8034892/nvlsp-v-united-states/
  • Note that it is docket number 19-1083.
• Click Buy on PACER for doc 10

Result in PACER:

• I am shown item 97 from docket number 19-1081.

Expected result:

• I should see doc 10 from docket number 19-1083 (FAIL)

2. Grab doc 10 from docket in PACER.

STR:

• Go here: https://www.courtlistener.com/docket/8034892/nvlsp-v-united-states/
  • Note that it is docket number 19-1083.
• Click "View on PACER" for the docket.
• Click "10" to buy doc 10 from the case.

Result in PACER:

• I am shown docket 19-1083, good.
• When I click on item 10 from that docket in PACER, it takes me to item 97 from docket 19-1081.

Expected result:

• I am shown docket 19-1083 (yes)
• I am shown document 10 from docket number 19-1083 (FAIL)

3. Experiment 2 from above, with RECAP disabled.

STR:

• Disable RECAP
• Do STR from item 2, above.

Results in PACER:

• I am shown docket 19-1083 (yes)
• I am shown doc 10 from docket 19-1083 (yes)

PASS!

---

It seems like we're doing something that is messing up the links, eh?

[ERosendo]

Yes. We're changing the default behavior of the links in PACER to avoid opening tabs. The current implementation of the extension removes the default onClick event from the document links and it's using the href attribute instead.

This href attribute is the same in docket number 19-1083 and in docket number 19-1801 and that's the cause of this issue. It seems like PACER needs more information to identify the docket entry associated with the document.

[mlissner]

Makes sense. I guess the onclick sends the PACER case ID as well? If so, I guess we're pretty safe just mirroring that as you proposed.

[ERosendo]

Yes, It does. The onClick envent submits a form that has the caseId and docId as hidden inputs. Here's the HTML of the form and the JS for the onClick event:

<form name="doDocPostURLForm" method="post" target="_blank" action="TransportRoom">
  <input name="servlet" type="hidden" value="ShowDoc">
  <input name="dls_id" type="hidden" value="">
  <input name="caseId" type="hidden" value="">
  <input name="dktType" type="hidden" value="dktPublic">
</form>


<script type="text/javascript">
function doDocPostURL(dls, caseIdStr){
  document.doDocPostURLForm.dls_id.value = dls;
  document.doDocPostURLForm.caseId.value = caseIdStr;
  document.doDocPostURLForm.submit();
  return false;
}
</script>

[mlissner]

Great. Please proceed with your fix. Glad we caught this in dev!

[ERosendo]

The fix I proposed will work for the extension ( the second experiment will pass) but I think the first experiment will still fail because CL's "Buy On PACER" links add a parameter called caseid in the query string but the name of the hidden input is caseId so the link from CL might redirect to the wrong receipt page. Here's an example:

the following links should take you to item 10 from docket number 19-1083:

• https://ecf.cafc.uscourts.gov/docs1/01301660046?caseId=13516 (this link works because we're adding the caseId parameter)
• https://ecf.cafc.uscourts.gov/docs1/01301660046?caseid=13516 (this link fails because we're adding the caseid instead of caseId)

[mlissner]

Cool. I just submitted a PR to fix this in CL and put you as the reviewer, @ERosendo.