feat(appellate): Adds guarding logic for missing pacer_doc_id

[ERosendo]

This PR adds a check to ensure that the pacer_doc_id is available before attempting to retrieve the PDF. If the pacer_doc_id is missing, the code will exit early to prevent unintended modifications to the page and incorrect GET requests.

This PR also updates the karma.config.js file to fix some failing tests

Fixes freelawproject/recap#388

[mlissner]

Seems simple enough, and LGTM. Let's see what Elisa thinks!

[elisa-a-v]

When following the steps described here to get docs from this docket, I got this page:

and the doc button brought me here:

I then selected the second attachment and the URL didn't include the doc ID (https://ecf.ca4.uscourts.gov/docs1/004110098892?caseId=null&recapAttNum=2), but the GET request did include it in the query params so that works!

Sadly, I noticed despite getting a 200 status response, the results list was empty, even though we have the docket, the docket entry and the RECAPDocument for that attachment (as seen in CL). Well, upon closer inspection I realized this part is actually fine, since we don't have the PDF for that RECAPDocument.

I then bought the document and could see it in the browser, but the POST request failed with a 400 status, because there was no pacer_doc_id in the payload:

I did not try to reproduce the issue with the live extension so as not to add to the DB issue 😅 so I'm not entirely sure this is a consequence of this PR or not, what do you think @ERosendo ?

[ERosendo]

Hey @elisa-a-v Thanks for your feedback! You have a great eye for catching cases that can break the code.

Your detailed report helped me identify an issue where the extension was incorrectly adding caseId=null to the attachment URLs.

Commit a538050 resolves this. I've tested the extension with the specific case you mentioned in your comment, and it successfully retrieved the document as expected.

[ERosendo]

I also believe adding support for this new page in the future would be beneficial. However, it falls outside the scope of this current PR, which is focused on fixing the GET request triggering the db performance issue.

[elisa-a-v]

Following the same steps as before and with the same docket, I could actually RECAP the doc successfully when clicking the doc icon in the attachment page:

This was the payload sent in the POST request after buying the doc:

But when I viewed the document by unselecting the other attachment and clicking "View Selected", I got a 400 status error response for the POST request.

So the issue actually persists, but only for this specific flow.

It seems to me like this might be related to these changes?

[ERosendo]

@elisa-a-v Thanks for the steps you outlined in your most recent comment! I followed them, but it seems we don't have enough data to upload the file on the document purchase page.

To address this, I made a small adjustment to the logic we introduced in #402. This change will make the extension return early in cases where the document ID can be retrieved. This way, we avoid adding unnecessary buttons or elements that might confuse users into thinking the extension is trying to upload the document.

I reviewed the GET requests and confirmed that the extension correctly sends the doc_id and avoids triggering the same problematic database query.

I think the problem with the combined PDF page should be included in issue #389 (freelawproject/recap#389), which aims to add support for the Orders/Judgments section.

[elisa-a-v]

Nice, I think the early return is the right call here.

I say we should merge this and dig deeper into the other stuff whenever we get to freelawproject/recap#389