Skip to content

Latest commit

 

History

History
113 lines (88 loc) · 4.66 KB

dependency-resolution.md

File metadata and controls

113 lines (88 loc) · 4.66 KB
Raw

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: 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 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: 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.

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.