Nhse o34 orkv.i87 linkcheck (OpenRiak#108)

martinsumner · web-flow · commit ef6437199a58 · 2026-01-07T10:38:09.000Z
Add link checking GHA, and fix the broken links it found
diff --git a/.github/workflows/linkcheck.yml b/.github/workflows/linkcheck.yml
@@ -0,0 +1,17 @@
+name: linkcheck
+
+on:
+  pull_request:
+    branches:
+      - openriak-3.4
+
+jobs:
+  check-links:
+    name: runner / linkspector
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Run linkspector
+        uses: umbrelladocs/action-linkspector@v1.4.0
+        with:
+          config_file: ./.linkspector.yml
diff --git a/.linkspector.yml b/.linkspector.yml
@@ -0,0 +1,6 @@
+dirs:
+  - docs
+files:
+  - ./README.md
+excludedDirs:
+  - docs/previous
diff --git a/README.md b/README.md
@@ -24,7 +24,7 @@ For later OTP versions, an alternative `openriak-<release>` branch will be requi
 
 ## Quick Start
 
-You should have [Erlang/OTP 26](http://erlang.org/download.html) to compile and run this version Riak KV. The [Riak application](https://github.com/OpenRiak/riak) is the parent application for Riak KV, providing a set of scripts to build, package, deploy and run a Riak KV store.
+You should have [Erlang/OTP 26](https://erlang.org/downloads.html) to compile and run this version Riak KV. The [Riak application](https://github.com/OpenRiak/riak) is the parent application for Riak KV, providing a set of scripts to build, package, deploy and run a Riak KV store.
 
 ## Quick Docs
 
diff --git a/docs/OperationsAndTroubleshootingGuide.md b/docs/OperationsAndTroubleshootingGuide.md
@@ -435,7 +435,7 @@ riak eval "application:set_env(riak_kv, log_readrepair, true)"
 
 ### Monitoring inter-cluster reconciliation
 
-For information on monitoring inter-cluster reconciliation and repair [refer to the NextGen Repl guide](./NextGenReplGuide.md#monitoring-and-run-time-changes).
+For information on monitoring inter-cluster reconciliation and repair [refer to the NextGen Repl guide](./ReplicationGuide.md#monitoring-and-runtime-changes).
 
 ### Monitoring node worker pools
 
@@ -690,7 +690,7 @@ Before considering backups, it is worth noting that as a distributed database th
 
 Production users of Riak commonly have relatively lightweight backup and recovery strategies when compared to traditional database management systems; eventual consistency allows the global recovery of state without the need to focus on recovering state first back to a point in time.  In general, greater effort is placed into building the resilience of the system, and also the management of change within the application i.e. ensuring the application adopts lazy migration strategies for schema changes that don't require large point-in-time migration events.
 
-If an individual node fails, do not restore an individual node from backup.  It is generally much more efficient and reliable to use [the `repair` process](#reactive-replace) to recover data on a node.  It is not normal practice to keep backups simply for the purpose of restoring individual nodes, even where those nodes may rely on ephemeral disks.
+If an individual node fails, do not restore an individual node from backup.  It is generally much more efficient and reliable to use [the `repair` process](#reactive-replacement) to recover data on a node.  It is not normal practice to keep backups simply for the purpose of restoring individual nodes, even where those nodes may rely on ephemeral disks.
 
 Note that in cloud environments, if an inefficient backup method is chosen (e.g. snapshots of block-service file-system volumes), then backup costs may consume a dominant proportion of overall Riak infrastructure costs.
 
diff --git a/docs/OtherAPI.md b/docs/OtherAPI.md
@@ -6,7 +6,7 @@ layout : default
 
 # Riak KV - Other APIs
 
-The majority of work within Riak KV can be done using the [Object API](/ObjectAPI.md), and the [Query API](/QueryAPI.md).  There are though additional APIs, with specific purposes:
+The majority of work within Riak KV can be done using the [Object API](./ObjectAPI.md), and the [Query API](./QueryAPI.md).  There are though additional APIs, with specific purposes:
 
 - [The AAE Fold API](#aae-fold-api)
 - [The Fetch API used to access replication queues](#the-fetch-api)
diff --git a/docs/QueryAPI.md b/docs/QueryAPI.md
@@ -63,7 +63,7 @@ The Query API is intended to provide flexible and performant functionality in th
 {: .highlight }
 > The aim of Riak development is to provide a database that performs efficient, scalable and predictable CRUD operations, and is just-queryable-enough to avoid the need of third party database integration in most use cases.
 
-Riak does support via [an external replication API](./NextGenReplGuide.md), the ability to manage replication and reconciliation to third party query engines (e.g. OpenSearch), should more complex query support be required.  The automation of such integration is outside of the current functional scope of Riak.
+Riak does support via [an external replication API](./ReplicationGuide.md#replication-api), the ability to manage replication and reconciliation to third party query engines (e.g. OpenSearch), should more complex query support be required.  The automation of such integration is outside of the current functional scope of Riak.
 
 ### Querying - Functional Summary
 
diff --git a/docs/ReplicationGuide.md b/docs/ReplicationGuide.md
@@ -100,7 +100,7 @@ The number of sink workers can be configured on the node:
   - The number of workers will constrain the pace at which events can be pulled from a source cluster, and also the PUSH workload that a sink cluster can generate for itself.
 - There is an overhead of a sink making requests on the source, so each sink worker will backoff if a request results in no replication events being discovered.
 - The sink worker pool does not auto-expand.
-  - Sufficient sink workers need to be configured to keep-up with real-time replication, though [this number can be adjusted at runtime](#changing-the-number-of-sink-workers).
+  - Sufficient sink workers need to be configured to keep-up with real-time replication, though [this number can be adjusted at runtime](#making-runtime-changes-to-the-sink).
   - There is some protection from over-provisioning but not from under-provisioning.
 
 In handling replication events, sink workers must apply the replicated change into the local cluster, and this uses a specific `PUSH` command.  The sink workers are constrained in that:
@@ -306,7 +306,7 @@ Reconciliation requires the scheduling of checks.  Each check will perform a ful
 - `branch_compare`;
 - `clock_compare`.
 
-The root to be compared is the root of [the merkle tree](./RiakTheoryGuide.md#handling-requests) representing the state of the whole tree in 1,024 4-byte hashes.  The roots are merged across all partitions, to provide a representation of cluster state in a single 4KB integer.
+The root to be compared is the root of [the merkle tree](./RiakTheoryGuide.md#anti-entropy) representing the state of the whole tree in 1,024 4-byte hashes.  The roots are merged across all partitions, to provide a representation of cluster state in a single 4KB integer.
 
 If these roots match between the clusters, the clusters are considered to be reconciled - `in_sync = true` is the result of the exchange, and `{root_compare, 0}` is the final state of the exchange.  If not, the `root_compare` is repeated, and on the repeated check only deltas in the same 4-byte hash as the previous compare need to be considered a potential mismatch.  The `root_compare` will be repeated until the intersection of deltas is empty (all 1,024 hashes, have a some stage in the loop, matched between roots), or there exists a stable set of branches in the root, which differ on every comparison.  An empty set of deltas will be considered an `in_sync = true` result, otherwise the next phase is required.
 
