Conversation
…ld-admin PM-4826 - make sure all task payments are kept on hold (admin)
…pprover PM-4825 - task payment approver
…task PM-4825 - show task payment details
…task PM-4830 payment modal task
…task PM-4830 - task creator details
What was broken Payments created for challenges that were still in Draft did not create a locked billing-account budget row, so the Billing Account Details modal did not include those draft challenge payments as Locked. Root cause (if identifiable) The finance billing-account helper only treated Active and Approved challenges as lockable, and manual challenge payment creation did not synchronize the aggregate challenge payment total into the billing-account ledger. What was changed Draft challenges now use the locked budget path. Manual challenge payment creation resolves the challenge, aggregates persisted USD payments for that challenge and billing account, and writes the aggregate amount to the billing-account locked or consumed row based on the challenge status. Generated challenge payment batches mark their per-winning requests so the existing aggregate sync remains the single writer. Any added/updated tests Added coverage for Draft challenge budget locking and manual challenge payment budget sync. Updated challenge payment generation tests to assert the internal budget-sync skip marker.
PM-4951: Lock draft challenge payment budget
What was broken Payments added to completed challenges from system admin could create finance payment rows without guaranteeing the challenge billing account was the account synchronized back to billing accounts. That left the work app BA popup at risk of missing the added payment in consumed budget. Root cause (if identifiable) The manual /winnings challenge-payment path used the billing account supplied in the payment detail as the sync target, instead of treating the challenge billing account as the source of truth. What was changed Manual challenge payments now validate caller-supplied USD payment details against the challenge billing account when challenge-api exposes one, then synchronize the aggregate challenge payment total against that challenge billing account. Existing fallback behavior remains for challenge payloads that do not expose billing metadata. Any added/updated tests Added WinningsService coverage for completed challenge payments syncing to consumed challenge BA budget and for rejecting manual challenge payments that target a different billing account.
What was broken Cancelling a challenge payment in wallet-admin only changed the finance payment status. The billing account consumed line item for the challenge external ID still included the cancelled payment amount. Root cause (if identifiable) The admin update path did not recalculate or overwrite the challenge billing-account budget row after moving a payment to CANCELLED. The existing challenge budget total query also counted cancelled payment rows. What was changed Added challenge budget synchronization to the admin cancellation flow so BA receives the remaining non-cancelled USD payment total for the affected challenge and billing account. Updated challenge budget total queries to exclude CANCELLED payments. Any added/updated tests Added an AdminService cancellation test covering BA resync after a challenge payment is cancelled. Updated the WinningsService budget sync expectation to exclude CANCELLED rows.
What was broken Cancelled challenge payment generation only treated CANCELLED_FAILED_REVIEW as payable, and cancelled budget sync only unlocked prior active locks. Cancelled challenges with reviewer payments could leave budget locked instead of consumed, while cancelled challenges with no payments did not reliably clear the lock. Root cause Finance keyed cancelled budget handling on the previous ACTIVE status instead of the aggregate generated payment total, and challenge payment generation did not accept all cancelled terminal statuses. What was changed Allowed cancelled challenge statuses through payment generation, while skipping winner and copilot payments so cancelled challenges only generate eligible reviewer payments. Updated billing-account synchronization so cancelled challenges with generated payment totals consume the budget, while cancelled challenges with a zero generated total unlock the budget. Any added/updated tests Added challenge service tests for cancelled winner and copilot skips plus zero-payment lock release. Added billing account service tests for cancelled generated-payment consumption and zero-payment unlock behavior.
PM-4960: sync admin challenge payments to challenge BA
PM-4958: Sync BA budget after payment cancellation
PM-4957: Fix cancelled challenge budget sync
What was broken Existing engagement payment backfill only populated finance payment challenge markup and challenge fee values. The billing-account consumed ledger rows that Work reads for BA line items could still contain only the member payment amount, so engagement payments did not include the challenge fee in BA consumed amounts. Root cause (if identifiable) The runtime engagement payment path now sends member payment plus challenge fee to billing-accounts-api-v6, but the historical backfill script stopped at the finance payment table and did not update matching billing-accounts ConsumedAmount rows. What was changed Extended the engagement challenge-fee backfill script to match finance engagement payment rows to billing-account consumed rows by assignment id, billing account, and creation order, then update consumed ledger amounts to total amount plus derived challenge fee. Added pre-update counts and post-update sample output for verification. Aligned an existing winnings service spec expectation with the current cancelled-payment filter used when syncing completed challenge payments. Any added/updated tests Updated the existing winnings service test expectation for the completed challenge payment billing-account sync query. No automated SQL backfill test was added because the script spans the finance and billing-accounts schemas directly.
PM-4900: Backfill engagement BA consumed fees
What was broken Cancelling an engagement payment from wallet-admin updated the finance payment status, but the engagement consumed row in the billing-account ledger stayed in place. The BA details modal still showed the cancelled engagement amount as consumed. Root cause (if identifiable) The previous PM-4958 fix only recalculated challenge payment budget rows. Engagement payments were explicitly excluded from that path, and their BA consumed rows are maintained separately from challenge budget rows. What was changed Added wallet-admin cancellation handling for engagement payments. After the finance status transaction succeeds, the admin service now recalculates the active non-cancelled engagement ledger amounts and asks the billing-account service to sync the matching consumed rows, deleting stale rows when cancelled payments should no longer reserve budget. The sync supports both the legacy challengeId BA ledger shape and the newer typed externalId/externalType shape. Any added/updated tests Added AdminService coverage for engagement payment cancellation triggering BA sync. Added BillingAccountsService coverage for deleting stale engagement consumed rows, syncing active typed rows, and syncing legacy aggregate rows.
PM-4958: Release engagement BA consumption on cancellation
Keep payment status
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://topcoder.atlassian.net/browse/PM-4826
https://topcoder.atlassian.net/browse/PM-4825
https://topcoder.atlassian.net/browse/PM-4830
https://topcoder.atlassian.net/browse/PM-4957
https://topcoder.atlassian.net/browse/PM-4958
https://topcoder.atlassian.net/browse/PM-4960