Feat: auto-unclaim stale recommendations

[diksha78dev]

Summary

This PR introduces a daily background maintenance routine that automatically unclaims stale recommendations after 14 days of inactivity (where no pull request is linked to the recommendation). It also alerts users on day 10 of inactivity to encourage them to submit their progress.

Type of Change

• Bug fix
• New feature
• UI / UX improvement
• Refactor
• Documentation
• Other

Related Issue

Closes #83

What was changed?

• Maintenance Cron (src/inngest/functions/maintenance.ts): Implemented the autoUnclaimStale Inngest function running daily at 00:30 UTC. It queries for claimed recommendations without a linked PR and reverts them to 'open' after 14 days, logging a 'claim_reset_stale' event. It also logs a 'claim_warning_stale' warning at the 10-day mark.
• Inngest Registration (src/app/api/inngest/route.ts): Registered the new cron function inside the main Inngest serve handler.
• User Activity Log (src/app/(app)/settings/usage/page.tsx): Mapped activity keys 'claim_reset_stale' and 'claim_warning_stale' to human-readable UI labels.
• Unit Tests (src/inngest/functions/maintenance.test.ts): Added a test suite using existing Supabase client mocking utilities to verify correct query window execution, atomic updates, and logging counts.

Screenshots

N/A (Backend maintenance logic and activity log dashboard updates)

Checklist

• My code follows the project structure and conventions
• I tested this locally (npm run dev)
• No hardcoded secrets or credentials
• I have updated documentation if needed

[vercel]

@diksha78dev is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Siddhartha-singh01]

Really nice implementation @diksha78dev using claimed_at + 14 days instead of
extending the original recommendation's expires_at is a thoughtful product
choice (each user gets a fresh window from when they claimed), and adding the
day-10 warning step wasn't asked for in #83 but is genuinely good UX. Releasing
back to status: 'open' (rather than expired) is also the right call frees the
user's claim slot AND re-surfaces the issue to others. The activity_log integration
with usage/page.tsx is the polish that makes this feature usable end-to-end.

One thing before merge: there's an unintended drop in the diff. The line

return { deleted: data?.length ?? 0 };

was removed from activityLogCleanup (an existing, unrelated function). Now that
function's step.run returns undefined and the Inngest run summary loses its
"deleted: N" visibility. Please restore that line.

Also a heads-up (non-blocking): your cron 30 0 * * * collides with #185's
flagSuspiciousXpAccounts, which uses the same minute. If both land, two daily jobs
fire simultaneously Inngest handles concurrency fine, but staggering one to
35 0 * * * keeps the logs cleaner. Could be a follow-up if #185 lands first.

Once the dropped return line is restored and CI goes green, this is ready to merge.
Solid first contribution

Thanks!

[diksha78dev]

Really nice implementation @diksha78dev using claimed_at + 14 days instead of extending the original recommendation's expires_at is a thoughtful product choice (each user gets a fresh window from when they claimed), and adding the day-10 warning step wasn't asked for in #83 but is genuinely good UX. Releasing back to status: 'open' (rather than expired) is also the right call frees the user's claim slot AND re-surfaces the issue to others. The activity_log integration with usage/page.tsx is the polish that makes this feature usable end-to-end.

One thing before merge: there's an unintended drop in the diff. The line

return { deleted: data?.length ?? 0 };

was removed from activityLogCleanup (an existing, unrelated function). Now that function's step.run returns undefined and the Inngest run summary loses its "deleted: N" visibility. Please restore that line.

Also a heads-up (non-blocking): your cron 30 0 * * * collides with #185's flagSuspiciousXpAccounts, which uses the same minute. If both land, two daily jobs fire simultaneously Inngest handles concurrency fine, but staggering one to 35 0 * * * keeps the logs cleaner. Could be a follow-up if #185 lands first.

Once the dropped return line is restored and CI goes green, this is ready to merge. Solid first contribution

Thanks!

i'll resolve those requested changes.

[diksha78dev]

@Siddhartha-singh01 I have made changes kindly review .
let me know if anything needs to add or fix i would be happy to work
thanks.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mergeship	Ready	Preview, Comment	May 22, 2026 2:35pm

[Ayush-Patel-56]

Cheers!

[diksha78dev]

@Ayush-Patel-56 can you add nsoc26 and level label if possible??

[Ayush-Patel-56]

Extremely sorry, Can you please highlight NSoC in PR description so while merging it'll be easy for us to add labels.

[diksha78dev]

'NSoc level1' label is not acceptable..
And you mentioned level: advanced so the level label should be 'level2' or 'level3'.

In future pr's I'll put nsoc26 so it will be easy for you...
Thanks...!