integreat/todos/009-pending-p2-standardize-temp-id-generation.md

status, priority, issue_id, tags, dependencies

status	priority	issue_id	tags	dependencies
pending	p2	009	testing patterns consistency vendors datomic

Standardize Temp ID Generation Pattern in vendors_test.clj

Problem Statement

The vendors test file uses inconsistent temp ID generation patterns:

1. (str "vendor-" (java.util.UUID/randomUUID)) in create-vendor helper
2. (str "vendor-" (rand-int 100000)) in test bodies
3. (str "vendor-source-" (rand-int 100000)) for merge tests

This inconsistency:

• Creates confusion about which pattern to use
• rand-int has collision risk (1 in 100,000 per test)
• Makes code harder to maintain

Findings

Inconsistent patterns identified by pattern-recognition-specialist:

Line 22:

(defn create-vendor ...
  {:db/id (str "vendor-" (java.util.UUID/randomUUID)) ...})

Lines 74, 96, 123, 140, 161:

(let [vendor-temp-id (str "vendor-" (rand-int 100000)) ...])
(let [source-temp-id (str "vendor-source-" (rand-int 100000)) ...])

accounts_test.clj pattern: Uses (rand-int 100000) consistently throughout.

Proposed Solutions

Option A: Standardize on UUID (Recommended)

Effort: Small (10 minutes) Risk: Low

Replace all (rand-int 100000) with (java.util.UUID/randomUUID):

;; Helper function
(defn- generate-temp-id [prefix]
  (str prefix "-" (java.util.UUID/randomUUID)))

;; Usage
(let [vendor-temp-id (generate-temp-id "vendor") ...]
(let [source-temp-id (generate-temp-id "vendor-source") ...]

Pros:

• Virtually zero collision probability
• Consistent across all tests
• UUID is standard for unique IDs

Cons:

• Slightly longer IDs (but doesn't matter for tests)
• Different from accounts_test.clj pattern

Option B: Standardize on rand-int (Matching accounts_test.clj)

Effort: Small (10 minutes) Risk: Low

Change create-vendor to use rand-int:

(defn create-vendor ...
  {:db/id (str "vendor-" (rand-int 100000)) ...})

Pros:

• Matches accounts_test.clj exactly
• Shorter IDs
• Simpler

Cons:

• Collision risk (though statistically low)
• UUID is more standard for uniqueness

Option C: Use Sequential IDs

Effort: Small (5 minutes) Risk: Low

Use simple sequential pattern:

;; No random generation needed
(let [vendor-temp-id "vendor-hydrate-test" ...])

Pros:

• Simplest possible
• No collision risk
• Self-documenting IDs

Cons:

• Different from accounts_test.clj
• Tests may fail if run concurrently (same IDs)

Recommended Action

Go with Option A - standardize on UUID:

1. Create helper function for consistency
2. Update all test temp IDs to use UUID
3. Update create-vendor helper to use UUID

This provides the safest pattern with zero collision risk.

Technical Details

Affected Lines:

• Line 22: create-vendor helper
• Lines 74, 96, 97, 123, 140, 161: Test temp IDs

Implementation:

(defn- temp-id [prefix]
  (str prefix "-" (java.util.UUID/randomUUID)))

;; Replace all instances:
(temp-id "vendor")           ; instead of (str "vendor-" (rand-int 100000))
(temp-id "vendor-source")    ; instead of (str "vendor-source-" (rand-int 100000))
(temp-id "vendor-target")    ; etc.

Verification:

lein test auto-ap.ssr.admin.vendors-test
lein cljfmt check

Acceptance Criteria

• Helper function created for temp ID generation
• All tests use consistent UUID-based temp IDs
• create-vendor helper updated
• Tests pass
• Code formatted with lein cljfmt

Work Log

2026-02-07 - Initial Creation

By: Pattern Recognition Specialist Agent

Actions:

• Identified inconsistent ID generation patterns
• Documented all occurrences
• Created todo for standardization

Learnings:

• accounts_test.clj uses rand-int consistently
• UUID provides better collision resistance
• Consistency across codebase is important for maintainability