Debugging Outdated Story Content

To verify the ID of the currently published revision in Draft API, you can go to:

https://<ORG>.arcpublishing.com/draft/v1/story/<ID>/revision/published

You should see a JSON object.

{
  "id": "MK5N7JSXZFCJLLRB576EG2H5IY",
  "document_id": "NSSO2FWM25G4ZCCHJK4LNOJDCA",
  "ans": { ... },
  "user_id": "user@example.com",
  "created_at": "2022-07-12T20:10:00.000Z",
  "type": "PUBLISHED"
}

In the example above, the published revision (id field) is MK5N7JSXZFCJLLRB576EG2H5IY.

In some cases, the content you receive from Draft API may not be what you expect. Ask yourself those questions:

In particular, for content that is updated in an automatic fashion, if you control this process, we recommend you log and monitor:

All the calls made to Draft API with the full URL, timestamp in UTC, and return error code 

Some errors your automated process may run into, which you should log and check on:

In general, if your content is updated automatically, one of those will be true:

If you need to open a support ticket, provide us with the logs mentioned above:

This will allow us to quickly find the request on our end, and we will be able to assist you more efficiently.

Let’s now look at Content API to make sure we see the same revision. To verify the ID of the currently published revision in Content API, you can go to:

https://<ORG>.arcpublishing.com/content-api/api/v4/?_id=<ID>&website=<WEBSITE>&published=true

Formatted:

https://<ORG>.arcpublishing.com/content-api/api/v4/
  ?_id=<ID>
  &website=<WEBSITE>
  &published=true

This call is slightly different, as you need to provide a website parameter. This would be the (or one) website ID where the content is published. The payload you will receive will also look different:

{
  "_id": "NSSO2FWM25G4ZCCHJK4LNOJDCA",
  ...
  "revision": {
    "revision_id": "MK5N7JSXZFCJLLRB576EG2H5IY",
    ...
  }
}

The field we are interested in is revision.revision_id. If the value is identical to what you saw in Draft API, then the problem is somewhere else, and you can go to the next section. If, however, the version is different, and you already tried re-publishing, then there might be a deeper issue, and you should open a support ticket.

Sometimes, errors can occur during rendering. If an error occurs during rendering and Web Delivery already has a copy of the page, it will serve the copy it has. This is called “serve stale”. The reasoning behind this logic is that it’s preferable to give the viewer a possibly outdated version of the page rather than giving them an error. In this situation, the content may have been updated with some incorrect data, and rendering fails, but the data is up-to-date in the source system (Content API, see previous section).

If you’ve already republished the content, and validated the version in both Content API and the Resovler Debugger, the next step is to check the rendering. To verify the rendering, you can take the URL of the content, /opinions/2022/07/12/this-is-a-title/, and then go to:

https://<ORG>.arcpublishing.com/pf/<URL>

So, in our case:

https://<ORG>.arcpublishing.com/pf/opinions/2022/07/12/this-is-a-title/

This URL triggers a direct render of the page through PageBuilder Engine. If the page fails to render, and returns an error, then this would explain why the public website does not reflect recent changes: due to the rendering error, Web Delivery is serving the stale version is has in its cache.

The fix for a rendering error depends. Often times, this is due to simple errors like an empty Author. The best way to verify is to check your PageBuilder Engine rendering logs.