Skip to content

Conversation

@windmountain
Copy link
Contributor

Before this change, users from June or maybe early July could not get AI codegen to work. The end result is that the chat gets stuck on a "..." response, the open router completions endpoint is returning 401, and refreshing the page just asks for log in again and winds up at the same place.

After this change, users with a vibes-openrouter-key with a createdAt before today will get a new one.

This should bring back all our users from Atlanta.

@windmountain windmountain requested review from jchris and necrodome July 29, 2025 18:50
@charliecreates charliecreates bot requested a review from CharlieHelps July 29, 2025 18:50
@netlify
Copy link

netlify bot commented Jul 29, 2025

Deploy Preview for fireproof-ai-builder ready!

Name Link
🔨 Latest commit fb3e536
🔍 Latest deploy log https://app.netlify.com/projects/fireproof-ai-builder/deploys/688917f9773e540009a89a0f
😎 Deploy Preview https://deploy-preview-182--fireproof-ai-builder.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Copy link
Contributor

@charliecreates charliecreates bot left a comment

Choose a reason for hiding this comment

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

Hard-coding the cut-off date to 2025-07-29 appears to contradict the PR description and likely prevents the desired key rotation. Additionally, keys lacking createdAt will slip through the expiration check, leaving some legacy or malformed entries untouched. Addressing these two issues will ensure the migration behaves as intended.

Summary of changes

What changed

  • Added a hard-coded epochStart constant (1753747200000 // 2025-07-29) inside checkLocalStorageForKey.
  • Introduced two new guards:
    1. isValid – ensures key+hash structure.
    2. isFromBefore – removes keys whose createdAt precedes epochStart.
  • Switched from in-place removal logic to throwing errors that funnel into the surrounding try/catch for cleanup.

Comment on lines +26 to +27
const epochStart = 1753747200000; // 2025-07-29T00:00:00.000Z

Copy link
Contributor

Choose a reason for hiding this comment

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

epochStart is documented in the PR as “today” (2024-07-29) but the timestamp here corresponds to 2025-07-29. Any key created between now and July 2025 will never be rotated, which contradicts the stated goal of expiring older keys.

Double-check the intended date; this looks like an off-by-one-year bug that could leave affected users stranded for another year.

Suggestion
// Use a correctly-dated epoch (midnight UTC on 2024-07-29)
const epochStart = Date.UTC(2024, 6, 29); // months are 0-indexed

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nobody said 2024. Go back to sleep.

Comment on lines +28 to +31
const isValid = keyData.key && typeof keyData.key === 'string' && keyData.hash;
const isFromBefore = keyData.createdAt && keyData.createdAt < epochStart;

if (!isValid) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If createdAt is missing, isFromBefore evaluates to false, meaning we keep keys whose age is unknown. Given the migration intent, it’s safer to treat a missing createdAt as stale rather than fresh, so that corrupted or legacy keys don’t block users.

Suggestion
const isFromBefore = !keyData.createdAt || keyData.createdAt < epochStart;

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, the approach you're proposing is too aggressive. I don't want to delete keys I don't understand.

@charliecreates charliecreates bot removed the request for review from CharlieHelps July 29, 2025 18:56
@jchris
Copy link
Contributor

jchris commented Jul 29, 2025

thanks, we removed openrouter keys in #174

@jchris jchris closed this Jul 29, 2025
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.

3 participants