[ParidelPooya]

Summary

A deployed test ran the same workflow on the JS, Python, and Java exporters, writing to S3 and Aurora. It found two problems with how record timestamps are compared.

1. The bundled Athena table declares emittedat, starttime, endtime, and the operation starttime/endtime as string. So Athena compares them as text. Measured on the deployed records: endtime >= '2026-10-23T18:42:46Z' returned none of the 7 records that ended in that second, because . sorts before Z. The same filter on a timestamp column returned all 7.
2. list_executions interpolated since and until as given. On destinations that compare text (DynamoDB, CloudWatch Logs Insights), a bound without a fraction, or with an offset such as -07:00, returned the wrong records. With an offset the error is hours.

Changes:

• Athena table: the CDK Glue table (cdk/stack.ts) and the telemetry-core DDL (athena.ts) declare those columns as timestamp. The S3 objects do not change; the OpenX JSON SerDe parses the ISO strings into the typed columns.
• Athena schema prompt (schema.ts): the columns are listed as timestamp (UTC). A new dialect rule says to compare them with TIMESTAMP literals or timestamp expressions, never strings.
• MCP list_executions: a new normalizeTimestamp validates each bound, including the calendar (it rejects 2026-02-30, which Date.parse would roll forward to March 2). A bound with no offset is read as UTC. Each dialect then writes its own literal:
  • Typed time columns (Athena timestamp, Aurora and Redshift timestamptz, OpenSearch date) compare instants. The bound keeps every digit the caller gave, because an existing table can hold values finer than a millisecond. Athena gets a TIMESTAMP '…' literal; the others get a quoted UTC string.
  • Text comparisons (DynamoDB, Logs Insights) get the stored format: UTC, 3 fraction digits, Z. A finer bound is rounded so it selects the same records: since up to the next millisecond, until down.
• Docs: the exporter README has a new "Timestamps" section that states the format contract. The MCP README describes how bounds are read. Both CHANGELOG entries are under Fixed. The Athena entry includes a migration note: a table created earlier keeps string columns until it is recreated or altered.

JS already writes every record timestamp with toISOString(), so the record format does not change here. Python and Java change to the same fixed-width format in sibling PRs:

• fix(telemetry): write fixed-width UTC record timestamps aws-durable-execution-sdk-python#821
• fix(telemetry): write fixed-width UTC timestamps aws-durable-execution-sdk-java#821

Testing

• Deployed check against the 18 real records in S3:
  • I created a temporary Athena table from the new buildCreateTableDdl output, then dropped it.
  • The SQL that buildListExecutionsSql now builds for since: "2026-10-23T11:42:46-07:00" returned the 3 executions in that window, from all three SDKs.
  • date_diff('millisecond', starttime, endtime) equals durationms.
  • Operation starttime/endtime read as timestamps.
  • A string comparison fails with TYPE_MISMATCH, as the prompt says.
• New timeBounds.test.ts (21 tests): the normalized forms, rejection of invalid dates and injection attempts, text order equal to time order after normalization, and the literal per destination. Updated the two injection.test.ts expectations.
• Package tests: MCP 427, core 385, exporter 159, vscode 34, desktop 48. All passed.
• biome ci on the repo: clean.
• Not run: a CDK deploy of the changed Glue table.

[github-actions]

Codex AI review

The prior P2 finding remains at packages/aws-durable-execution-sdk-js-telemetry-mcp/src/sqlSafe.ts:203 (maintainer verdict: out-of-scope). No additional findings. Tests and deployment checks were not executed under the review constraints.

Suppressed repeats

• arf_v1_gghgogdvp6bq3z5ddo33tyxswv — out-of-scope (maintainer verdict)

Reviewed commit 7abc7c3885501986d6c74dcc4b601195b0a095f2. Workflow run