Symptom (user-reported)
The Account and Payment columns are now shown, but they have no data, only a dash ("-").
PR #713 added the Account, Term, Payment, Monthly Cost columns to the Approval queue. The columns render, but every row shows - for Account, Payment, and (when not already set) Monthly Cost.
Root cause
The data lives in the right place on the backend but executionToHistoryRow / projectRecommendationFields in internal/api/handler_history.go never copy it onto the synthesised PurchaseHistoryRecord:
- Account:
executionToHistoryRow reads exec.CloudAccountID, but pending executions created by the web bulk-purchase flow (handler_purchases.go near L1399, the only constructor for these rows) never set CloudAccountID. The per-recommendation CloudAccountID IS available via recs[i].CloudAccountID but is not consulted.
- Payment:
projectRecommendationFields populates Service, ResourceType, Region, Term, UpfrontCost, EstimatedSavings, and (single-rec only) MonthlyCost from the recommendation, but never sets row.Payment in either branch — even though RecommendationRecord.Payment exists and is populated by every constructor.
- MonthlyCost (multi-rec only): same gap; only the single-rec branch maps it.
Net effect: the frontend reads account_id == "" and payment == "" and renders the - fallback for every Approval-queue row.
Proposed fix
In internal/api/handler_history.go:
executionToHistoryRow: when exec.CloudAccountID == nil, fall back to recs[i].CloudAccountID collapsed via a new collapseRecommendationAccount helper (mirrors collapseRecommendationProvider). Returns the shared value across recs, or "" when they disagree (the - rendering then stays correct for an honestly-heterogeneous basket).
projectRecommendationFields:
- Single-rec: set
row.Payment = r.Payment alongside the existing field projections.
- Multi-rec: set
row.Payment = collapseRecommendationPayment(recs) (same pattern) and row.MonthlyCost = sum(recs[i].MonthlyCost).
Add regression tests:
- Extend
TestHandler_getHistory_IncludesPending so its recs carry CloudAccountID, Payment, and MonthlyCost; assert the pending row carries AccountID, Payment, MonthlyCost.
- New single-rec sub-test that asserts a 1-rec execution passes Payment through.
- Extend
history-approval-queue.test.ts with a test that mocks the API response with the three populated fields and asserts the cells show real values, not the - fallback.
Followup to
#713 (merged) — this is the second pass on the same change, fixing the data-population gap on the backend side.
Symptom (user-reported)
PR #713 added the Account, Term, Payment, Monthly Cost columns to the Approval queue. The columns render, but every row shows
-for Account, Payment, and (when not already set) Monthly Cost.Root cause
The data lives in the right place on the backend but
executionToHistoryRow/projectRecommendationFieldsininternal/api/handler_history.gonever copy it onto the synthesisedPurchaseHistoryRecord:executionToHistoryRowreadsexec.CloudAccountID, but pending executions created by the web bulk-purchase flow (handler_purchases.gonear L1399, the only constructor for these rows) never setCloudAccountID. The per-recommendationCloudAccountIDIS available viarecs[i].CloudAccountIDbut is not consulted.projectRecommendationFieldspopulatesService,ResourceType,Region,Term,UpfrontCost,EstimatedSavings, and (single-rec only)MonthlyCostfrom the recommendation, but never setsrow.Paymentin either branch — even thoughRecommendationRecord.Paymentexists and is populated by every constructor.Net effect: the frontend reads
account_id == ""andpayment == ""and renders the-fallback for every Approval-queue row.Proposed fix
In
internal/api/handler_history.go:executionToHistoryRow: whenexec.CloudAccountID == nil, fall back torecs[i].CloudAccountIDcollapsed via a newcollapseRecommendationAccounthelper (mirrorscollapseRecommendationProvider). Returns the shared value across recs, or""when they disagree (the-rendering then stays correct for an honestly-heterogeneous basket).projectRecommendationFields:row.Payment = r.Paymentalongside the existing field projections.row.Payment = collapseRecommendationPayment(recs)(same pattern) androw.MonthlyCost = sum(recs[i].MonthlyCost).Add regression tests:
TestHandler_getHistory_IncludesPendingso its recs carryCloudAccountID,Payment, andMonthlyCost; assert the pending row carriesAccountID,Payment,MonthlyCost.history-approval-queue.test.tswith a test that mocks the API response with the three populated fields and asserts the cells show real values, not the-fallback.Followup to
#713 (merged) — this is the second pass on the same change, fixing the data-population gap on the backend side.