Week 033 — The Reward Math

A reward field with a "Max" button sounds simple until you think about what happens when a user saves, then changes the amount again.

Week of June 30, 2025

Progress

Points balance and stars balance fields were added to all user classes — DTO, service, repository. The update logic needed to handle edge cases: when subtracting from a balance, the result can't go negative. An exception is thrown when that constraint is violated.

The reward saving path required updates to ItemService, LostItemDTO, and supporting code. Rewards are saved as part of the LostItemDTO, not the item directly.

The "Max" button wiring had a math issue: setting the reward to the user's maximum available balance, then saving, produced a valid result. But saving again in the same session used the pre-save balance rather than the just-saved one — leading to miscalculations. The fix was to load the items page on a successful save rather than staying on the item page, resetting state on every save.

Decision Made

After a successful item save, navigate to the items page rather than staying on the item page. This prevents the in-session balance calculation drift. It's a slightly less fluid UX, but state bugs in financial calculations are worse than an extra page load.

The Question That Appeared

The reward update flow allows users to reduce their balance by allocating a reward. It should not allow them to increase their balance through this field — only legitimate credits (subscription points, finder rewards from someone returning their item) should add to a balance. Sending a negative reward amount through the API could potentially increase a balance. This needs a backend check.

Next Week

Found page validation and the anonymous finder case — what happens when a finder isn't registered and submits a found report.