feat(world-aws): AWS World implementation for Workflow DevKit

[stewartjarod]

Summary

• New @wraps.dev/world-aws package — AWS-backed World implementation for Vercel Workflow DevKit using DynamoDB (storage + streams) and SQS (queue)
• Storage layer — Full run/step/event/hook/wait lifecycle backed by DynamoDB with TTL, pagination, batch writes with retry, and HKDF-SHA256 encryption
• Queue layer — SQS-based queue with dual-protocol handler (body envelope for Lambda, header-based for local dev), idempotency keys, and delay support
• Lambda handler — createSQSHandler() with partial batch failure reporting and configurable timeout/sleep handling
• Streamer — DynamoDB Streams-based event streaming with cursor tracking and iterator recovery
• Local dev SQS poller — start() automatically bridges SQS to local HTTP server when PORT or WORKFLOW_LOCAL_BASE_URL is set
• Setup CLI — world-aws-setup bin for creating DynamoDB tables and SQS queues
• E2E integration — Wired up @workflow/world-testing suite (addition, idempotency, hooks, null bytes, error handling) with per-run queue isolation
• 214 unit tests covering storage, queue, streamer, Lambda handler, config, encryption, marshal, util, tables, pagination, TTL, batch-write, duration, and errors

Test plan

• cd packages/world-aws && pnpm test — 214 unit tests pass (no AWS needed)
• AWS_REGION=us-east-1 AWS_ACCOUNT_ID=<id> pnpm test:world — 6 e2e tests pass (requires SST dev running + AWS credentials)
• pnpm build — package compiles to ESM + CJS with type declarations
• pnpm typecheck — no type errors

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
wraps-web	Ready	Preview, Comment	Feb 25, 2026 4:17pm
wraps-website	Ready	Preview, Comment	Feb 25, 2026 4:17pm

In general, to fix this problem, we should ensure that user-controlled data used in request URLs is strictly validated and/or encoded, especially when used as a path segment. We want to prevent characters that could alter the URL structure (like /, \, ?, #) or inject additional path elements, while preserving the existing functionality of referencing automations by their IDs.

The best approach here is to introduce a small, local validator for automation IDs (for example, restricting them to a sane character set such as alphanumerics, dashes, and underscores) and use its sanitized / validated result when constructing the URL. If the provided automationId does not match the allowed pattern, we can fail early and return an error result instead of issuing the HTTP request. This keeps the hostname and base path unchanged, prevents any path traversal or malformed ID injection, and minimally impacts behavior for legitimate IDs.

Concretely, within apps/web/src/actions/automations.ts:

1. Add a helper function near callAutomationScheduleApi (or above it) such as sanitizeAutomationId or isValidAutomationId that:
   • Checks that the ID is non-empty and matches a safe regex, e.g. /^[A-Za-z0-9_-]{1,128}$/.
   • Returns a boolean or throws/returns an error string.
2. In callAutomationScheduleApi, before constructing url, validate automationId using that helper.
   • If invalid, log (optionally) and return { success: false, error: "Invalid automation ID" } without calling fetch.
   • If valid, use the original automationId (the same string) when building the URL, since we've ensured it can't contain dangerous characters.
3. Because all the tainted flows (from updateAutomation, deleteAutomation, enableAutomation, disableAutomation) share the same sink (callAutomationScheduleApi), validating in this one place will fix all four alert variants without changing the public function signatures.

No extra imports are strictly required; this can be done with basic TypeScript and a regex.

General fix: Avoid letting untrusted data influence the format string of logging/formatting functions. Either (a) place untrusted data into subsequent arguments while using %s placeholders in a constant format string, or (b) avoid format-string-style logging entirely and log structured data (objects) or concatenate strings safely.

Best fix here: We can keep the existing logging behavior but move all dynamic/tainted values into a separate argument rather than interpolating them into the first string. For example, instead of:

console.error(
  `[automation-schedule] API ${action} error for ${automationId}:`,
  error
);

we can log a constant string as the first argument and pass details as an object:

console.error(
  "[automation-schedule] API error",
  { action, automationId, error }
);

This removes any dependency of the format string on untrusted input (automationId) and also addresses all CodeQL variants associated with the same call site (no matter whether automationId came from updateAutomation, deleteAutomation, enableAutomation, or disableAutomation). This change preserves functionality (we still log the same conceptual information, arguably more clearly) and requires no new imports or helpers, and is confined to the provided snippet in apps/web/src/actions/automations.ts.

Specific location:

• File: apps/web/src/actions/automations.ts
• Function: callAutomationScheduleApi
• Lines: 213–217, replacing the console.error call to avoid a template literal that embeds action/automationId.

No additional methods or imports are needed.