Skip to content

feat(routines): return the day's description from get_workout_for_date - #21

Open
wromansky wants to merge 1 commit into
wger-project:masterfrom
wromansky:feat/day-description-in-workout
Open

feat(routines): return the day's description from get_workout_for_date#21
wromansky wants to merge 1 commit into
wger-project:masterfrom
wromansky:feat/day-description-in-workout

Conversation

@wromansky

Copy link
Copy Markdown
Contributor

The problem

A routine's per-day description is where the notes live that the numbers alone do not carry: rep ranges, which machine substitutes for which, form cues. get_workout_for_date is documented as "the one call that answers 'what am I doing today'", and it returned the prescribed sets, reps and RiR while dropping the field that says on what terms.

The gap is not academic. A day whose description reads "working reps = lower end of range: bench 6-8, press 8-10" prescribes a range, and the stored repetitions value is its bottom. A caller working only from the payload reports "6" and "8" as fixed targets — which is what the routine's author was trying to prevent by writing the note in the first place. The information already exists, one field away, on an object this function resolves anyway.

The change

One field: day_description, alongside day_name, from the day object get_workout_for_date already has in hand. Unset becomes null, the same treatment day_name gets, so the key is always present and no sentinel crosses the tool boundary.

Docstring, README tool table and CHANGELOG updated to match.

Why here rather than in the caller

The alternative is telling every caller to make a second get_routine_day call to fetch the description. That is a round trip per session for a field the server has already loaded, and it only helps callers that know to ask — which is the ones that already understand the problem. Returning it from the default read path means the notes arrive with the plan they annotate, for everyone, at no extra request.

Tests

Two existing tests extended rather than new ones added, since both already cover this exact boundary:

  • test_returns_slot_entry_ids_for_today asserts the description reaches the caller.
  • test_unnamed_day_still_answers now also sets description to UNSET and asserts None, pinning the sentinel treatment next to the day_name case it already guarded.

Verified they bite: with the new field removed from the source, both fail (one KeyError). Full suite 247 passed, ruff check clean.

Note

Touches get_workout_for_date's return dict and docstring. Independent of #16, #17, #18, #19 and #20; the only shared file is CHANGELOG.md's ## Unreleased block, which is a one-hunk conflict for whichever lands second.

A routine's per-day description is where the notes live that the numbers
alone do not carry: rep ranges, which machine substitutes for which, form
cues. get_workout_for_date is documented as "the one call that answers
'what am I doing today'", and it was returning the prescribed sets, reps
and RiR while dropping the field that says on what terms.

The gap is not academic. A day whose description reads "working reps =
lower end of range: bench 6-8, press 8-10" prescribes a range, and a
caller working only from the payload reports "6" and "8" as fixed
targets. The information exists, one field away, on an object this
function already resolves.

Unset comes back as null, the same treatment day_name already gets, so
the field is always present and never leaks a sentinel across the tool
boundary.
@wromansky
wromansky marked this pull request as ready for review September 2, 2026 02:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant