publishing-api: Dependency Resolution
Contents
Introduction
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: DependencyResolutionJob. The dependency resolution process itself is triggered as a result of different Sidekiq workers (DownstreamDraftJob, DownstreamLiveJob, and DownstreamDiscardDraftJob) 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 docs/link-expansion.md
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: DownstreamDraftJob and DownstreamLiveJob. 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_idof the item that initiated dependency resolution, an empty value for this implies the request was not the result of dependency resolution.
Debugging
You can explore dependency resolution in the rails console by creating a
DependencyResolution instance.
> dependency_resolution = DependencyResolution.new(content_id, 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
information.