OrbitPayLearner

First contribution

Your first meaningful pull request

Recommended for a stated reason, with the context needed to ship it. Onboard never opens a pull request on your behalf.

OrbitPay demo data. Connect your sources to generate this from your own repositories, Slack, and Linear.

PAY-231low risk2-4 hoursgood-first-issuepayments-workerreliability

Prevent duplicate retry scheduling

scheduleRetry can enqueue the same (intentId, attemptCount) pair twice when two workers pick up the same attempt. Add a dedupe guard in the scheduler and log the scheduling decision so reconciliation can see it.

Suitability92/100

Why this issue

Touches retryQueue.ts and reconcile.ts, both of which Maya read in the checkout trace and the retry module.
Directly downstream of the investigation she just completed, so the mental model is already loaded.
Two files changed, no schema migration, and no processor interaction.
retryQueue.test.ts already exists, so the change is testable without new infrastructure.
Low production risk: a dedupe guard is fail-safe. Worst case a retry is scheduled once instead of twice.

Open in Linear Create a branch

Waiting on manager approval before you start.

Why it matters

Duplicate retry scheduling is invisible until the ledger drifts the next morning, and reconciling drift is manual work for the one engineer who understands it. Closing this removes a recurring source of both duplicate processor fees and single-owner toil.

Architecture recap

scheduleRetry writes (intentId, attemptCount) into a Redis sorted set keyed by due time. Workers poll for due members. Because the poll and the write are not atomic, two workers can pick up the same attempt and each schedule the next one.

Files to inspect

src/retry/retryQueue.ts
scheduleRetry is where the dedupe guard belongs. Note the existing NOTE comment pointing at PAY-247.
src/ledger/reconcile.ts
Add the scheduling decision to the reconciliation log so a duplicate is visible in the trail, not just in the ledger.

Suggested sequence

1Reproduce the duplicate locally by invoking scheduleRetry twice for one attempt.
2Add the failing test first so the guard has something to prove.
3Implement the dedupe inside scheduleRetry rather than at the call sites.
4Add the scheduling decision to the reconciliation log line.
5Run the retry suite, then open a draft pull request and request Dev Shah.

Test requirements

Extend retryQueue.test.ts with a case where the same attempt is scheduled twice concurrently.
Assert exactly one member lands in the sorted set for a given (intentId, attemptCount).
Keep the existing happy-path test green without modifying it.

Known edge cases

An attempt that legitimately advances to attemptCount + 1 must still schedule; the guard is per pair, not per intent.
Redis is not transactional across the poll and the write, so the guard needs to be atomic on its own.
Entries older than the retry ceiling are pruned by a separate sweeper. Do not let the guard resurrect them.

A similar change that already shipped

The closest precedent in this repository, and a good model for how the reviewer expects this kind of change to be tested.

payments-worker#402 · Add full jitter to retry backoff

The PAY-184 fix. Same file, same review path, and a good model for how Dev expects retry changes to be tested.

Related discussion

Slack

#payments · Why the worker owns retries

92%

Dev Shah: We deliberately kept retries out of checkout-api. If the API retried inline, a degraded processor would eat our request pool and take the whole storefront down with it. The worker can back off for minutes without anyone noticing.

Dev ShahFeb 19, 2026Open source

Slack

#payments · Reconciliation logs are unreadable

90%

Lucas Moreau: Every reconciliation run logs one line per attempt with no scheduling context. When a retry gets scheduled twice you cannot tell from the logs, only from the ledger drift the next morning.

Lucas MoreauJun 30, 2026Open source

Issues Onboard considered and ranked lower

A manager can replace the recommendation with one of these.

PAY-247medium risk61/100 suitability

Add unique constraint on payment_attempts

Same subsystem as PAY-231 and conceptually related.
Requires a schema migration and a backfill of existing duplicates, which is higher risk for a first contribution.
Blocked until PAY-231 lands.

PAY-252low risk34/100 suitability

Settlement table pagination in merchant-dashboard

Genuinely small and low risk.
Lives in merchant-dashboard, which is outside Maya's target repositories and owned by another engineer.
Teaches nothing about the payment stack she was onboarded onto.

Onboard

OrbitPayLearner

First contribution

Your first meaningful pull request

Recommended for a stated reason, with the context needed to ship it. Onboard never opens a pull request on your behalf.

OrbitPay demo data. Connect your sources to generate this from your own repositories, Slack, and Linear.

PAY-231low risk2-4 hoursgood-first-issuepayments-workerreliability

Prevent duplicate retry scheduling

Suitability92/100

Why this issue

Touches retryQueue.ts and reconcile.ts, both of which Maya read in the checkout trace and the retry module.
Directly downstream of the investigation she just completed, so the mental model is already loaded.
Two files changed, no schema migration, and no processor interaction.
retryQueue.test.ts already exists, so the change is testable without new infrastructure.
Low production risk: a dedupe guard is fail-safe. Worst case a retry is scheduled once instead of twice.

Open in Linear Create a branch

Waiting on manager approval before you start.

Why it matters

Architecture recap

Files to inspect

src/retry/retryQueue.ts
scheduleRetry is where the dedupe guard belongs. Note the existing NOTE comment pointing at PAY-247.
src/ledger/reconcile.ts
Add the scheduling decision to the reconciliation log so a duplicate is visible in the trail, not just in the ledger.

Suggested sequence

1Reproduce the duplicate locally by invoking scheduleRetry twice for one attempt.
2Add the failing test first so the guard has something to prove.
3Implement the dedupe inside scheduleRetry rather than at the call sites.
4Add the scheduling decision to the reconciliation log line.
5Run the retry suite, then open a draft pull request and request Dev Shah.

Test requirements

Extend retryQueue.test.ts with a case where the same attempt is scheduled twice concurrently.
Assert exactly one member lands in the sorted set for a given (intentId, attemptCount).
Keep the existing happy-path test green without modifying it.

Known edge cases

An attempt that legitimately advances to attemptCount + 1 must still schedule; the guard is per pair, not per intent.
Redis is not transactional across the poll and the write, so the guard needs to be atomic on its own.
Entries older than the retry ceiling are pruned by a separate sweeper. Do not let the guard resurrect them.

A similar change that already shipped

The closest precedent in this repository, and a good model for how the reviewer expects this kind of change to be tested.

payments-worker#402 · Add full jitter to retry backoff

The PAY-184 fix. Same file, same review path, and a good model for how Dev expects retry changes to be tested.

Related discussion

Slack

#payments · Why the worker owns retries

92%

Dev Shah: We deliberately kept retries out of checkout-api. If the API retried inline, a degraded processor would eat our request pool and take the whole storefront down with it. The worker can back off for minutes without anyone noticing.

Dev ShahFeb 19, 2026Open source

Slack

#payments · Reconciliation logs are unreadable

90%

Lucas Moreau: Every reconciliation run logs one line per attempt with no scheduling context. When a retry gets scheduled twice you cannot tell from the logs, only from the ledger drift the next morning.

Lucas MoreauJun 30, 2026Open source

Issues Onboard considered and ranked lower

A manager can replace the recommendation with one of these.

PAY-247medium risk61/100 suitability

Add unique constraint on payment_attempts

Same subsystem as PAY-231 and conceptually related.
Requires a schema migration and a backfill of existing duplicates, which is higher risk for a first contribution.
Blocked until PAY-231 lands.

PAY-252low risk34/100 suitability

Settlement table pagination in merchant-dashboard

Genuinely small and low risk.
Lives in merchant-dashboard, which is outside Maya's target repositories and owned by another engineer.
Teaches nothing about the payment stack she was onboarded onto.