BigQuery Loader 2.2.1

docs/api-reference/loaders-storage-targets/bigquery-loader/configuration-reference/_common_config.md

@@ -51,6 +51,20 @@ import Link from '@docusaurus/Link';
     <td><code>retries.transientErrors.attempts</code></td>
     <td>Optional. Default value 5. Maximum number of attempts to make before giving up on a transient error.</td>
 </tr>
+<tr>
+    <td><code>retries.alterTableWait.delay</code></td>
+    <td>
+      <p>Optional. Default value <code>1 second</code>.</p>
+      <p>Configures backoff when waiting for the BigQuery Writer to detect that the loader has altered the table by adding new columns.</p>
+    </td>
+</tr>
+<tr>
+    <td><code>retries.tooManyColumns.delay</code></td>
+    <td>
+      <p>Optional. Default value <code>300 seconds</code>.</p>
+      <p>Relevant when the BigQuery table is close to exceeding the limit on max allowed columns in a single table. The loader will ignore a failure to alter the table due to too many columns, and it will continue to run. Some events will inevitably go to the failed events output topic until new columns have been added. This parameter configures how often the loader will retry to alter the table after an earlier failure.</p>
+    </td>
+</tr>
 <tr>
     <td><code>skipSchemas</code></td>
     <td>
@@ -135,6 +149,14 @@ import Link from '@docusaurus/Link';
     <td><code>monitoring.webhook.heartbeat.*</code></td>
     <td>Optional. Default value <code>5.minutes</code>. How often to send a heartbeat event to the webhook when healthy.</td>
 </tr>
+<tr>
+    <td><code>monitoring.healthProbe.port</code></td>
+    <td>Optional. Default value <code>8000</code>. Open a HTTP server that returns OK only if the app is healthy.</td>
+</tr>
+<tr>
+    <td><code>monitoring.healthProbe.unhealthyLatency</code></td>
+    <td>Optional. Default value <code>5 minutes</code>. Health probe becomes unhealthy if any received event is still not fully processed before this cutoff time.</td>
+</tr>
 <tr>
     <td><code>monitoring.sentry.dsn</code></td>
     <td>Optional. Set to a Sentry URI to report unexpected runtime exceptions.</td>

docs/api-reference/loaders-storage-targets/bigquery-loader/configuration-reference/_pubsub_config.md

@@ -2,6 +2,10 @@
     <td><code>input.subscription</code></td>
     <td>Required, e.g. <code>projects/myproject/subscriptions/snowplow-enriched</code>. Name of the Pub/Sub subscription with the enriched events</td>
 </tr>
+{/* Do not document `input.parallelPullFactor`, `input.maxMessagesPerPull` or `input.debounceRequests` here.
+    Those options are only relevant for unary pull, and BigQuery Loader (as of 2.2.1) uses streaming pull
+    (the common-streams default), so they have no effect for this loader.
+    If the loader ever switches to unary pull, they become relevant and should be documented. */}
 <tr>
     <td><code>input.durationPerAckExtension</code></td>
     <td>Optional. Default value <code>15 seconds</code>. Pub/Sub ack deadlines are extended for this duration when needed.</td>
@@ -15,18 +19,6 @@
       will wait until there is <code>1.5 seconds</code> left of the remaining deadline, before re-extending the message deadline.
     </td>
 </tr>
-<tr>
-    <td><code>input.maxMessagesPerPull</code></td>
-    <td>Optional. Default value 1000. How many Pub/Sub messages to pull from the server in a single request.</td>
-</tr>
-<tr>
-    <td><code>input.debounceRequests</code></td>
-    <td>
-      Optional. Default value <code>100 millis</code>.
-      Adds an artifical delay between consecutive requests to Pub/Sub for more messages.
-      Under some circumstances, this was found to slightly alleviate a problem in which Pub/Sub might re-deliver the same messages multiple times.
-    </td>
-</tr>
 <tr>
     <td><code>input.retries.transientErrors.delay</code> (since 2.1.0)</td>
     <td>

src/componentVersions.js

@@ -28,7 +28,7 @@ export const versions = {
   snowbridge: '5.1.1',
 
   // Loaders
-  bqLoader: '2.2.0',
+  bqLoader: '2.2.1',
   bqLoader1x: '1.7.2',
   esLoader: '3.0.1',
   gcsLoader: '0.5.7',