fix: Use UUID for idempotency key to scale to concurrent users

[jonathanpopham]

Summary

Replace timestamp-based idempotency key with UUID to eliminate collision risk at scale.

Problem

The previous timestamp-based key (repoName:deadcode:commitHash:timestamp) could theoretically collide if two users analyze the same repo at the same commit in the exact same millisecond.

Solution

Use crypto.randomUUID() instead of Date.now():

return `${repoName}:deadcode:${commitHash}:${randomUUID()}`;

This guarantees uniqueness with zero collision risk, regardless of concurrent usage.

Test plan

• Build succeeds
• Re-run workflow to verify no 409 conflicts

Summary by CodeRabbit

• Refactor
  • Updated idempotency key generation to use UUID-based identification instead of timestamp-based approach for enhanced uniqueness and reliability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The idempotency key generation mechanism in src/index.ts has been updated to use UUID-based values instead of timestamp-based values, changing the uniqueness approach from time-dependent to randomly generated identifiers while maintaining the same key structure.

Changes

Cohort / File(s)	Summary
Idempotency Key Generation src/index.ts	Replaced timestamp with UUID in idempotency key composition. The key format changed from repoName:deadcode:commitHash:timestamp() to repoName:deadcode:commitHash:randomUUID(). This switches uniqueness guarantees from time-based ordering to random generation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🎲 A timestamp once marked the way,
But UUIDs now hold their sway,
Random instead of tick-tock time,
Idempotent keys in their prime! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: replacing a timestamp-based idempotency key with UUID to handle concurrent users, which directly aligns with the actual code modification.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c1b6505 and fdaa6e8.

⛔ Files ignored due to path filters (1)

• dist/index.js is excluded by !**/dist/**

📒 Files selected for processing (1)

• src/index.ts

🔇 Additional comments (2)

src/index.ts (2)

6-6: LGTM on the import!

crypto.randomUUID() is the right way to generate UUIDs in Node.js - it's built-in, cryptographically strong, and available since Node.js v14.17.0. No extra dependencies needed. 👍

---

117-118: Quick heads-up: This changes the retry behavior of your action.

So here's the thing - "idempotency key" usually means "if I send the same request twice with this key, I get the same result and no duplicate work happens." Think of it like a deduplication ID.

Before (timestamp): If the action failed and retried within the same millisecond, the API would recognize it as a retry and return the cached result (or 409 if already processing). Two different users hitting the same repo/commit in the same ms = collision (bad).

After (UUID): Every single call gets a brand new key. So:

• Two users can now analyze the same repo/commit simultaneously without collision ✅
• BUT if the network hiccups and your action retries, it will trigger a completely new analysis instead of resuming/deduping ⚠️

If retries triggering duplicate analyses is fine for your use case, this is totally cool! But if you want "one analysis per workflow run" specifically, you might want to use github.context.runId instead:

return `${repoName}:deadcode:${commitHash}:${github.context.runId}`;

This gives you:

• Unique per workflow run (no collisions between different runs)
• Stable across retries within the same run (true idempotency)

Just depends on what behavior you actually want!

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}