Skip to content

Comments

fix: harden vary dimensions with path safety and bigint regression test#436

Merged
stack72 merged 1 commit intomainfrom
fix/vary-review-feedback
Feb 23, 2026
Merged

fix: harden vary dimensions with path safety and bigint regression test#436
stack72 merged 1 commit intomainfrom
fix/vary-review-feedback

Conversation

@stack72
Copy link
Contributor

@stack72 stack72 commented Feb 23, 2026

Summary

Addresses review feedback from #435 (vary dimensions for environment-isolated
data storage). Two non-blocking suggestions were made during review — this PR
implements both.

Changes

1. Path safety validation in composeDataName()

composeDataName() now rejects vary values containing path-unsafe characters:

  • Path separators (/, \) — prevents values like ../../etc from
    creating data outside the expected directory
  • Relative path components (., ..) — prevents directory traversal

Current usage is safe since vary values come from controlled workflow inputs,
but this hardens the function against future use cases where values may come
from less trusted sources.

Error messages are clear and actionable:

Vary value at index 0 contains path separator characters: ../../etc
Vary value at index 0 must not be a relative path component: ..

2. Explicit bigint regression test for data.version()

Added a test that simulates the real DataCache behavior — a Map with
number keys — to verify that CEL int values (which JavaScript represents
as bigint) are correctly converted to Number() before cache lookup.

This test would have caught the latent bug fixed in #435 where
Map.get(1n) silently returned undefined when the key was 1 (number),
causing data.version() to return null.

The test covers both:

  • 3-arg form: data.version("scanner", "result", 1)
  • 4-arg form with vary: data.version("scanner", "result", ["prod"], 1)

Test coverage

  • 4 new unit tests for path safety validation
  • 1 new regression test for bigint-to-number conversion
  • All 1867 tests pass

Verification

  • deno check — pass
  • deno lint — pass
  • deno fmt — pass
  • deno run test — 1867 passed, 0 failed
  • deno run compile — pass

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

…gression test

Address review feedback from #435:

1. Path safety validation in composeDataName(): Vary values that contain
   path separators (/ or \) or relative path components (. or ..) are now
   rejected with clear error messages. This prevents vary values from
   creating data outside the expected directory structure, hardening
   against future use cases where vary values may come from untrusted
   sources.

2. Explicit bigint regression test: Added a test that simulates the
   DataCache's strict number-keyed Map.get() behavior to verify that CEL
   int values (which may be bigint) are correctly converted to number
   before cache lookup. This covers both the 3-arg and 4-arg (with vary)
   forms of data.version(), preventing regression of the fix from #435.

Test coverage:
- 4 new unit tests for path safety (forward slash, backslash, .., .)
- 1 new regression test for bigint-to-number conversion
- All 1867 tests pass

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Summary

Approved - This PR cleanly addresses the review feedback from #435.

Changes Verified:

  1. Path safety validation in composeDataName() - Correctly rejects vary values containing:

    • Path separators (/, \)
    • Relative path components (., ..)
    • Clear, actionable error messages
  2. Bigint regression test - Validates that CEL int values (bigint) work correctly with data.version() cache lookup

Checklist:

  • ✓ TypeScript strict mode, no any types
  • ✓ Named exports (no default exports)
  • ✓ AGPLv3 license headers present
  • ✓ Unit tests next to source files
  • @std/assert assertions used
  • ✓ Security: Path traversal prevention is a good hardening measure

DDD Review:

The composeDataName function correctly implements domain validation as a pure function, enforcing invariants on valid data names in the domain layer.

Suggestions (non-blocking):

The regex /[\/\\]/ could be simplified to /[/\\]/ (forward slashes don't need escaping in character classes), but this is purely stylistic - the current version is correct.

@stack72 stack72 merged commit 2287bdf into main Feb 23, 2026
4 checks passed
@stack72 stack72 deleted the fix/vary-review-feedback branch February 23, 2026 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant