@smart-cloud/publisher-exporter 1.1.64 → 1.1.65

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -174,9 +174,9 @@ Prune old archive directories with `publisher-exporter prune-logs --runtime-dir
174
174
  ## Optional Lambda workers
175
175
 
176
176
  The exporter includes protocol-v1 building blocks for delegating bounded
177
- render, text-rewrite, and S3 deploy-copy tasks to container-image Lambda
177
+ render, asset-fetch, text-rewrite, and S3 deploy-copy tasks to container-image Lambda
178
178
  functions. Large payloads do not travel in the Lambda response: workers write
179
- HTML and detailed results below a configured S3 workspace prefix and return a
179
+ HTML, assets, and detailed results below a configured S3 workspace prefix and return a
180
180
  small `resultKey` pointer. Reusing the same job/task ID is idempotent.
181
181
 
182
182
  The companion CDK application is maintained separately at
@@ -199,11 +199,20 @@ per invocation so retries stay small and Lambda concurrency supplies the
199
199
  parallelism. The Lambda response is not the rendered body; read the returned
200
200
  S3 result object using the same temporary role credentials.
201
201
 
202
- Enable the desired Lambda phases in the Static Publisher WordPress admin. The saved
203
- runtime configuration contains only the operational settings:
202
+ Enable unified Lambda processing in the Static Publisher WordPress admin. The
203
+ single Processing concurrency value is dual-written to the legacy per-phase
204
+ fields for mixed-version compatibility. In unified mode, HTML and asset bodies
205
+ remain in the workspace through rewrite and direct S3-to-S3 deployment; the
206
+ coordinator transfers only task/result metadata. Older mixed phase settings
207
+ remain supported until an administrator changes the common controls. A current
208
+ `remote-workers.json` must contain render, asset, rewrite, and deploy-copy aliases.
209
+
210
+ The saved runtime configuration remains compatible with older exporters:
204
211
 
205
212
  ```json
206
213
  {
214
+ "lambdaDelegationEnabled": true,
215
+ "processingConcurrency": 4,
207
216
  "remoteWorkers": {
208
217
  "render": {
209
218
  "enabled": true,
@@ -212,13 +221,13 @@ runtime configuration contains only the operational settings:
212
221
  },
213
222
  "rewrite": {
214
223
  "enabled": true,
215
- "concurrency": 8,
224
+ "concurrency": 4,
216
225
  "batchSize": 25,
217
226
  "maxAttempts": 2
218
227
  },
219
228
  "deploy": {
220
229
  "enabled": true,
221
- "concurrency": 8,
230
+ "concurrency": 4,
222
231
  "batchSize": 50,
223
232
  "maxAttempts": 2
224
233
  }
@@ -235,16 +244,15 @@ STATIC_PUBLISHER_RUNTIME_DIR=/srv/site/runtime \
235
244
  publisher-exporter crawl --remote-render
236
245
  ```
237
246
 
238
- Use `--local-render` to override an enabled configuration for a diagnostic run.
239
- The crawl coordinator keeps sitemap discovery, incremental decisions, asset
240
- downloads, manifests, and deploy planning local. Each admitted
241
- page is rendered by one Lambda task, and its HTML is read from S3 with length
242
- and SHA-256 verification. Failed/deferred tasks receive a new task ID when
243
- retried. Final text files are staged in the workspace, rewritten in bounded
244
- Lambda batches, checksum-verified, and restored to the local export tree.
245
- Deployment stages finalized objects with their cache and checksum metadata;
246
- deploy workers then check or copy them directly from S3 to the allowlisted
247
- target. Only explicit deploy-plan tombstones may be deleted. Each completed
247
+ Use `--local-render` only as a legacy render diagnostic override; it disables
248
+ the unified remote data path for that crawl. The coordinator keeps sitemap
249
+ discovery, incremental and safety decisions, compact manifests, and deploy
250
+ planning local. Each admitted page is rendered by one Lambda task. Its HTML
251
+ stays in S3, while the result returns discovered pages/assets and an object
252
+ reference. Asset workers fetch and inspect bounded URL batches. Final text
253
+ objects are rewritten in place by Lambda, then deploy workers check or copy
254
+ them directly from the workspace to the allowlisted target. Only explicit
255
+ deploy-plan tombstones may be deleted. Each completed
248
256
  batch updates phase-scoped runtime progress and adds a structured batch summary
249
257
  to `deploy.log.jsonl`; debug logging also records each returned object result.
250
258
  There is no silent local fallback for any