Fix: Keep Batch Submission Disabled While a Payment Job Is Active

[jahrulezfrancis]

Problem

The "Submit Batch" button re-enables as soon as the initial queueing
request returns — while the payment job is still running in the background
— letting a user submit an overlapping second job for the same batch.

Severity: High
Location: components/dashboard/BatchReview.tsx:151-166,440-447, contexts/BatchFlowContext.tsx:345-374

Description

BatchReview's handleSubmit sets a local isSubmitting flag, awaits
onSubmit(...), then clears it in finally. But the context-level
onSubmit resolves as soon as /api/batch-submit returns its initial
queueing response — it calls startPolling(jobId, publicKey) without
awaiting it, so the actual job status (queued/processing/complete) is never
reflected back to the caller. The submit button's disabled prop
(components/dashboard/BatchReview.tsx:445) reads only this local
isSubmitting flag, not the context's job-status state, so it re-enables
almost immediately. Because the idempotency key is derived from the payment
list itself, changing the skip/convert selection before resubmitting
produces a genuinely different key — the backend treats it as a new job, not
a duplicate.

Steps to Reproduce

1. Submit a batch containing recipients A and B; receive the queued
   response.
2. Before the job reaches a terminal state, change the review selection to
   skip B.
3. Submit again — the button is enabled because the local flag was already
   cleared.
4. The new job (containing only A) runs alongside the original job (A and
   B) — recipient A can be paid by both.

Expected Behavior

Submission controls should stay locked based on the actual job lifecycle
state, not a component-local flag that clears on the initial HTTP response.

Suggested Fix Approach

Drive the button's disabled state from the context's job-status (queued /
processing / terminal), and block a second submission while an active job
exists for the same review session.

Acceptance Criteria

• Submit button stays disabled until the active job reaches a terminal
  state
• Changing the review selection mid-job does not allow a second,
  overlapping submission
• Test confirms no duplicate idempotency key/job is possible while a
  prior job is still active
• Existing single-submission flow is unaffected

---

[Bolajiomo99]

Hi team, I'd like to claim the final slot for this issue. I can fix this high-severity submission bug by refactoring the 'Submit Batch' button to read its disabled state directly from the global context's active job lifecycle state (queued/processing) rather than the local component flag. I will ensure the controls stay locked until the background job reaches a terminal state, preventing any overlapping submissions or duplicate payment risks. Ready to add the necessary tests and open a clean PR.

[grantfox-oss]

🦊 GrantFox — @Bolajiomo99 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #698)
2. Your PR will be reviewed by the Batch-Pay maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@Bolajiomo99's PR #726 was approved and merged by @jahrulezfrancis.

🏆 @Bolajiomo99: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (156 total points). Track your full progress on GrantFox.

👏 Great work, @Bolajiomo99! Keep contributing to Batch-Pay.