feat(subscription): enhance sync functionality to include email searc…

[Apexone11]

…h and broader subscription status checks

[sourcery-ai]

Sorry @Apexone11, you have reached your weekly rate limit of 1500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[Copilot]

Pull request overview

Enhances the payments self-service subscription sync endpoint to find a user’s Stripe customer(s) more reliably (metadata + email) and to detect additional subscription statuses when repairing the local Subscription record.

Changes:

• Fetch the authenticated user’s email from the DB and use it as an additional Stripe customer lookup path.
• Aggregate candidate Stripe customer IDs from both metadata search and email list results.
• Expand subscription status checks during sync to include active, trialing, and past_due, and return more descriptive failure messaging.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Customer lookup by email makes it possible to sync a subscription that doesn’t actually belong to the logged-in user (e.g., if an account can be created/updated with an email they don’t control, or if the Stripe customer was created outside StudyHub but shares the same email). Consider only using the email-based customer matches as candidates and then requiring a positive match on customer.metadata.studyhub_user_id or subscription.metadata.studyhub_user_id before syncing; also skip any customer whose metadata points at a different StudyHub user.

[Copilot]

Before upserting the subscription for req.user.userId, the code should validate that the Stripe object being used actually belongs to that StudyHub user (e.g., sub.metadata.studyhub_user_id or the customer’s metadata.studyhub_user_id). Without this, any matching customerId (especially from the email search) can result in attaching the wrong Stripe subscription/customer to the current user.

[Copilot]

The nested loops can trigger up to ~3 Stripe API calls per matched customer (and up to 20 customerIds), which risks slow responses/timeouts and unnecessary Stripe load. Consider listing subscriptions once per customer (e.g., request all statuses in one call if supported) and then filtering locally, rather than calling subscriptions.list separately for each status.

Suggested change

	for (const status of statusesToCheck) {
	if (synced) break
	try {
	const subs = await stripe.subscriptions.list({
	customer: customerId,
	status,
	limit: 1,
	})
	for (const sub of subs.data) {
	const priceId = sub.items?.data?.[0]?.price?.id || ''
	const resolved = planFromPriceId(priceId)
	const plan = resolved || 'pro_monthly'
	await prisma.subscription.upsert({
	where: { userId: req.user.userId },
	create: {
	userId: req.user.userId,
	stripeCustomerId: customerId,
	stripeSubscriptionId: sub.id,
	stripePriceId: priceId,
	plan,
	status: sub.status,
	currentPeriodStart: new Date(sub.current_period_start * 1000),
	currentPeriodEnd: new Date(sub.current_period_end * 1000),
	cancelAtPeriodEnd: sub.cancel_at_period_end,
	},
	update: {
	stripeCustomerId: customerId,
	stripeSubscriptionId: sub.id,
	stripePriceId: priceId,
	plan,
	status: sub.status,
	currentPeriodStart: new Date(sub.current_period_start * 1000),
	currentPeriodEnd: new Date(sub.current_period_end * 1000),
	cancelAtPeriodEnd: sub.cancel_at_period_end,
	canceledAt: null,
	},
	})
	synced = true
	log.info(
	{ userId: req.user.userId, plan, subId: sub.id, customerId },
	'User self-synced subscription',
	)
	break
	}
	} catch {
	// Continue with next status
	}
	}
	if (synced) break
	if (synced) break
	try {
	const subs = await stripe.subscriptions.list({
	customer: customerId,
	status: 'all',
	limit: 100,
	})
	const sub = statusesToCheck
	.map((status) => subs.data.find((candidate) => candidate.status === status))
	.find(Boolean)
	if (!sub) continue
	const priceId = sub.items?.data?.[0]?.price?.id || ''
	const resolved = planFromPriceId(priceId)
	const plan = resolved || 'pro_monthly'
	await prisma.subscription.upsert({
	where: { userId: req.user.userId },
	create: {
	userId: req.user.userId,
	stripeCustomerId: customerId,
	stripeSubscriptionId: sub.id,
	stripePriceId: priceId,
	plan,
	status: sub.status,
	currentPeriodStart: new Date(sub.current_period_start * 1000),
	currentPeriodEnd: new Date(sub.current_period_end * 1000),
	cancelAtPeriodEnd: sub.cancel_at_period_end,
	},
	update: {
	stripeCustomerId: customerId,
	stripeSubscriptionId: sub.id,
	stripePriceId: priceId,
	plan,
	status: sub.status,
	currentPeriodStart: new Date(sub.current_period_start * 1000),
	currentPeriodEnd: new Date(sub.current_period_end * 1000),
	cancelAtPeriodEnd: sub.cancel_at_period_end,
	canceledAt: null,
	},
	})
	synced = true
	log.info(
	{ userId: req.user.userId, plan, subId: sub.id, customerId },
	'User self-synced subscription',
	)
	} catch {
	// Continue with next customer
	}

[Copilot]

These empty catch {} blocks swallow Stripe errors silently, which makes it hard to debug real production failures (e.g., bad credentials, network issues, malformed query). Consider logging at least a warning/debug with enough context (userId + which search path failed) and/or capturing the error, while still gracefully degrading.

[Copilot]

The catch {} here drops the Stripe error and continues, which can mask systemic issues (e.g., Stripe outage or auth failure) and lead to confusing "No active subscription" responses. Consider logging (include customerId and status) and distinguishing between "not found" vs "Stripe call failed" so support can diagnose sync failures.