Bug
The workout-session summary endpoint (/api/workout-sessions/[sessionId]/summary) misattributes reps and weight whenever the set columns aren't in the order [REPS, WEIGHT], producing wildly wrong totalReps, totalVolume, and totalWeightLifted.
Root cause
In app/api/workout-sessions/[sessionId]/summary/route.ts:
if (set.types.includes("REPS") && set.valuesInt.length > 0) {
const reps = set.valuesInt[0]; // assumes REPS is column 0
totalReps += reps;
if (set.types.includes("WEIGHT") && set.valuesInt.length > 1) {
const weight = set.valuesInt[1]; // assumes WEIGHT is column 1
totalVolume += weight * reps;
totalWeightLifted += weight;
}
}
Set columns are user-reorderable (the type <select> lets a user change any column to any type). The canonical storage keeps each value at its column index, so:
reps lives at valuesInt[set.types.indexOf("REPS")]
weight lives at valuesInt[set.types.indexOf("WEIGHT")]
When a set is configured as [WEIGHT, REPS] (e.g. weight first), the current code reads valuesInt[0] (the weight) as reps and valuesInt[1] (the reps) as weight — so a 100 lb × 8 set becomes reps = 100, weight = 8, reporting totalVolume += 800 instead of 800... but a 80 kg × 5 set stored as [WEIGHT,REPS] reads reps=80, weight=5 → volume 400 instead of 400... the numbers are silently scrambled, and a single valuesInt.length > 1 guard even leaks the wrong field when only one column exists.
The sibling stats routes (statistics/volume, statistics/one-rep-max, weight-progression) all do this correctly via types.indexOf(...). This summary route is the only one with the hardcoded assumption.
Fix
Read the values by their type index:
const repsIndex = set.types.indexOf("REPS");
const weightIndex = set.types.indexOf("WEIGHT");
if (repsIndex !== -1 && set.valuesInt?.[repsIndex]) {
const reps = set.valuesInt[repsIndex];
totalReps += reps;
if (weightIndex !== -1 && set.valuesInt?.[weightIndex]) {
const weight = set.valuesInt[weightIndex];
totalVolume += weight * reps;
totalWeightLifted += weight;
}
}
I have a PR ready.
Bug
The workout-session summary endpoint (
/api/workout-sessions/[sessionId]/summary) misattributes reps and weight whenever the set columns aren't in the order[REPS, WEIGHT], producing wildly wrongtotalReps,totalVolume, andtotalWeightLifted.Root cause
In
app/api/workout-sessions/[sessionId]/summary/route.ts:Set columns are user-reorderable (the type
<select>lets a user change any column to any type). The canonical storage keeps each value at its column index, so:repslives atvaluesInt[set.types.indexOf("REPS")]weightlives atvaluesInt[set.types.indexOf("WEIGHT")]When a set is configured as
[WEIGHT, REPS](e.g. weight first), the current code readsvaluesInt[0](the weight) as reps andvaluesInt[1](the reps) as weight — so a 100 lb × 8 set becomesreps = 100, weight = 8, reportingtotalVolume += 800instead of800... but a80 kg × 5set stored as[WEIGHT,REPS]readsreps=80, weight=5→ volume400instead of400... the numbers are silently scrambled, and a singlevaluesInt.length > 1guard even leaks the wrong field when only one column exists.The sibling stats routes (
statistics/volume,statistics/one-rep-max,weight-progression) all do this correctly viatypes.indexOf(...). This summary route is the only one with the hardcoded assumption.Fix
Read the values by their type index:
I have a PR ready.