Two failure paths were swallowing their errors. 1. handleCollect returned early when the photo upload failed. Status was already flipped to `collected` at that point, but the early return skipped `setItems`, leaving a successfully-collected item on screen still looking un-collected. The driver re-collected it and re-attempted the same oversized upload — one record picked up 29 failed attempts in a single morning. The item now clears off the list either way, and a photo failure is a warning toast telling the driver to add it from the office, not a silent stall. 2. handleProblem logged nothing. PocketBase puts the real reason in `response.data` keyed by field name; the top-level message is always the useless "Something went wrong while processing your request." That is exactly what hid the problem_type mismatch fixed separately in PB today: the select was missing out_of_stock/partial_stock/quality_issue/wrong_item, so four of the five Report Problem buttons 400'd with no visible reason. |
||
|---|---|---|
| .. | ||
| login | ||
| map | ||
| settings | ||
| .DS_Store | ||
| globals.css | ||
| layout.tsx | ||
| page.tsx | ||