@smart-cloud/publisher-exporter 1.1.65 → 1.1.67

package/README.md

@@ -181,7 +181,7 @@ small `resultKey` pointer. Reusing the same job/task ID is idempotent.
 
 The companion CDK application is maintained separately at
 [`smartcloudsol/static-publisher-lambda-workers`](https://github.com/smartcloudsol/static-publisher-lambda-workers).
-directory. Its deploy script emits a `remote-workers.json` containing the
+Its deploy script emits a `remote-workers.json` containing the
 versioned Lambda alias ARNs, workspace bucket/prefix, region, and generated
 assumable role. The file contains no static AWS access keys.
 
@@ -194,10 +194,12 @@ publisher-exporter remote-worker-health \
   --runtime-dir /srv/site/runtime
 ```
 
-Protocol v1 accepts 1-20 same-origin URLs per render task. Start with one URL
-per invocation so retries stay small and Lambda concurrency supplies the
-parallelism. The Lambda response is not the rendered body; read the returned
-S3 result object using the same temporary role credentials.
+Protocol v1 accepts 1-20 same-origin URLs per render task. The default render
+batch size is 5, so a warm Chromium process can render several pages
+sequentially in one invocation while Lambda concurrency supplies parallelism
+between batches. Only failed or deferred URLs are retried. The Lambda response
+is not the rendered body; read the returned S3 result object using the same
+temporary role credentials.
 
 Enable unified Lambda processing in the Static Publisher WordPress admin. The
 single Processing concurrency value is dual-written to the legacy per-phase
@@ -206,6 +208,17 @@ remain in the workspace through rewrite and direct S3-to-S3 deployment; the
 coordinator transfers only task/result metadata. Older mixed phase settings
 remain supported until an administrator changes the common controls. A current
 `remote-workers.json` must contain render, asset, rewrite, and deploy-copy aliases.
+When it also contains `status.tableName`, the exporter reads strongly consistent
+DynamoDB heartbeats while a synchronous Lambda invocation is running and
+forwards them to the existing runtime progress snapshot. Workers write those
+rows directly with conditionally increasing sequence numbers.
+
+Workers prefer the origin response `Content-Type`, fall back to the resource
+extension only when the header is absent or invalid, and preserve that value
+when writing transformed HTML, CSS, JavaScript, or other text back to S3. The
+deploy worker includes `Content-Type` in its unchanged-object decision. After
+upgrading from an earlier delegated rewrite implementation, republish affected
+targets to replace already incorrect object metadata.
 
 The saved runtime configuration remains compatible with older exporters:
 
@@ -217,6 +230,7 @@ The saved runtime configuration remains compatible with older exporters:
     "render": {
       "enabled": true,
       "concurrency": 4,
+      "batchSize": 5,
       "maxAttempts": 2
     },
     "rewrite": {
@@ -247,9 +261,9 @@ STATIC_PUBLISHER_RUNTIME_DIR=/srv/site/runtime \
 Use `--local-render` only as a legacy render diagnostic override; it disables
 the unified remote data path for that crawl. The coordinator keeps sitemap
 discovery, incremental and safety decisions, compact manifests, and deploy
-planning local. Each admitted page is rendered by one Lambda task. Its HTML
-stays in S3, while the result returns discovered pages/assets and an object
-reference. Asset workers fetch and inspect bounded URL batches. Final text
+planning local. Admitted pages are grouped into bounded Lambda batches. Their
+HTML stays in S3, while each result returns discovered pages/assets and an
+object reference. Asset workers fetch and inspect bounded URL batches. Final text
 objects are rewritten in place by Lambda, then deploy workers check or copy
 them directly from the workspace to the allowlisted target. Only explicit
 deploy-plan tombstones may be deleted. Each completed