-
Notifications
You must be signed in to change notification settings - Fork 35
Expire old openrouter key #182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for fireproof-ai-builder ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this 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
epochStartconstant (1753747200000 // 2025-07-29) insidecheckLocalStorageForKey. - Introduced two new guards:
isValid– ensures key+hash structure.isFromBefore– removes keys whosecreatedAtprecedesepochStart.
- Switched from in-place removal logic to throwing errors that funnel into the surrounding
try/catchfor cleanup.
| const epochStart = 1753747200000; // 2025-07-29T00:00:00.000Z | ||
|
|
There was a problem hiding this comment.
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-indexedReply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.
There was a problem hiding this comment.
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.
| const isValid = keyData.key && typeof keyData.key === 'string' && keyData.hash; | ||
| const isFromBefore = keyData.createdAt && keyData.createdAt < epochStart; | ||
|
|
||
| if (!isValid) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
thanks, we removed openrouter keys in #174 |
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
createdAtbefore today will get a new one.This should bring back all our users from Atlanta.