Table of contents

Publishing API: Dependency resolution



Dependency resolution is a concept within the Publishing API to describe the
process of determining which editions require being re-presented to a
Content Store as a result of a change in another edition.

The Content Stores contain static JSON representations of document editions.
There are links between content and the details of these links are stored in
this JSON representation. The process for determining and presenting these
links is called link expansion. Any time an edition
changes there could be many different editions that require
re-presenting. Dependency resolution is the process to determine which items
require this.

When it occurs

Dependency resolution occurs in a background process provided by a
Sidekiq worker:
DependencyResolutionWorker. The dependency
resolution process itself is triggered as a result of different Sidekiq
workers (DownstreamDraftWorker,
DownstreamLiveWorker, and
DownstreamDiscardDraftWorker) who are
responsible for updating the Content Stores any time an edition changes.

Thus any time an edition is updated and re-presented in the content store
the dependency resolution process will run and update items linked to the
document of the edition. This means that for a single edition update there
can be many requests to the Content Stores.

Determining editions to re-present

When an edition of document, A has been updated all content that include a
link to A in their JSON links may need updating. The process of dependency
resolution determines the content_id of every item, and then re-presents
that item in each locale that is available.

For reference of the types of links see

The class responsible for determining which content_ids require updates is
DependencyResolution. It uses the
link expansion rules to perform the inverse process of
link expansion.

The Queries::ContentDependencies class is responsible
for determining the locales of each content_id.

Updating Content Store

As a result of the dependency resolution process, editions identified to
be presented will be queued in the Sidekiq workers:
DownstreamDraftWorker and
DownstreamLiveWorker. These workers communicate
with the content store.

Content Store HTTP headers

HTTP Requests to the Content Store contain HTTP headers that can be used
to determine the origin of the request:

  • Govuk-Request-Id - An ID associated with the initial HTTP request which triggered the request to the Publishing API
  • Govuk-Dependency-Resolution-Source-Content-Id - The content_id of the item that initiated dependency resolution, an empty value for this implies the request was not the result of dependency resolution.


You can explore dependency resolution in the rails console by creating a
DependencyResolution instance.

> dependency_resolution =, locale: :en, with_drafts: true)

You can then print the link_graph of the link expansion to view
the links.

> dependency_resolution.link_graph.to_h
=> {:children=>[
     {:content_id=>"4ff219a8-f2e6-4fca-9b73-ebaebc9c7b6a", :links=>{}}

You can navigate through the link_graph object for further debugging