CDR Tickets

~bkline, it appears that every attempt to create a PP report for this DIS creates an unpublished version of the document in Drupal.  There are currently 20 unpublished "versions" for this document in Drupal.  The PP report for other DIS works as expected. 

Is it correct for the PP report to create a document in Drupal?  I didn't think it is but my experience with the new PP report is very limited.

Yes. That's how the PP subsystem is able to reflect so faithfully the layout for the document as it will look when it is published. This is what summary PP does:

1. send the version the user has select to Drupal, storing a node with the negative version of the CDR ID (to distinguish it as a temporary document, not the live version seen on the web site by the public)

2. ask Drupal for the rendered page for the newly created node

3. delete the temporary node

4. show the user the rendered page

It seems that for this document ended up with step 3 failing (perhaps a user submitted the same publish preview request twice, one immediately after the other).

I have deleted all the temporary documents (there were lots of them – the users should be aware that once a PP document gets into this state, trying again will never succeed until the problem is cleaned up, it will only make that cleanup harder by creating dozens of nodes to be deleted).

I see that the published document has a draft, which as far as I can see is indistinguishable from the version the public sees. Both are marked as updated October 18, 2019. Does anyone know what the latest change made to this document might be? If no one objects, I propose to publish the draft, in case the presence of that draft version was in any way involved in the PP failure. Then I will ask the users to test PP again (probably best not to do that before the draft is taken care of).

Is there a way to find out how many PDQ documents might have such a DRAFT version which might block future PP reports?  

Maybe you could show me sometime how to remove a node so that I could take care of the clean-up next time.

I never got an answer about whether I should publish the draft for CDR495778, and now it appears that the draft is no longer present (perhaps overtaken by the Friday job).

As far as I have been able to tell from my analysis following my previous comment above, the presence of a draft and the PP failures are unrelated. In other words, the fact that a summary has a draft does NOT prevent publish preview from working correctly (as long as users are patient and don't slam the server with multiple requests for the same preview at once).

Is there a way to find out how many PDQ documents might have such a DRAFT version ...

I pulled down a copy of the production database and ran some queries. There are 127 such drafts. See attachment.

... which might block future PP reports?

No, as noted above, the presence of the draft does not appear to prevent PP from working. As far as I can tell, all of the docs on the list are previewable. Let me know if you run into counter examples (being careful not to submit multiple simultaneous preview requests for the same document).

Sorry for the delay in responding. PP does work for this DIS now. Does it matter if requests for PP for a particular document are made by different users almost at the same time? Would that cause the same problem or it has to be from the same user for this problem to happen? Also, could there be a better solution for this problem rather than making sure that no successive requests for PP are made for a particular document? I don't think we can control that in all circumstances.

Don't really know many details about the exact conditions needed to cause the problem. It would be unlikely, but possible, for two different users to submit requests close enough in time to create the problem. If exercising reasonable care to avoid bursts of multiple requests for preview of the same document by the same user doesn't eliminate most of the issues, we may have to examine other measures, but for now let's try this approach.

Okay. We will document any new cases that come up to see if there is the need to revisit this issue. Thanks!

We just came across another occurrence of this problem but this time, it is for a summary document 62675.

Drupal's in the middle of a deployment right now. I'll take a look later.

I can see that this is indeed the same issue as we saw with the DIS.  There are currently 5 copies of the same document with negative CDR-ID all created within a span of 6 minutes.

Fixed. Should work now.

Since we're changing the publish preview script for the gatekeeper retirement release anyway, I have made some additional modifications to try and prevent these failures, whatever may be the cause for them. Please test CIS and DIS publish preview on DEV to make sure I haven't broken it.

We've finished testing PP for DIS and CIS on DEV and they look good. Thanks!

We've had one more incident of the error for CDR ID 256672.

Fixed. You may see more of these until the gatekeeper retirement code is deployed, but I'm hoping after that happens this problem will be a thing of the past.

I'll leave you to close this one, ~oseipokuw, whenever you're satisfied that the problem has been fixed.

This issue has not happened again since the gatekeeper retirement release so I am closing this ticket. Thank you!!