Skip to content

fix(customers): default a Place location so signup with a place works - #293

Merged
roncodes merged 1 commit into
dev-v0.6.60from
fix/customer-place-location-default
Aug 10, 2026
Merged

fix(customers): default a Place location so signup with a place works#293
roncodes merged 1 commit into
dev-v0.6.60from
fix/customer-place-location-default

Conversation

@roncodes

@roncodes roncodes commented Aug 8, 2026

Copy link
Copy Markdown
Member

The bug

POST /v1/customers accepts an optional place object, and the payload documented in the Postman collection sends one. Creating it always failed:

SQLSTATE[HY000]: General error: 1364
Field 'location' doesn't have a default value

places.location is a POINT NOT NULL column with no database default, and the attribute allow-list in resolveCustomerPlace is address-only — a caller cannot supply coordinates through this surface — so Place::create() was always called without one.

Every documented signup that included a place returned a 500.

The fix

Default it to Point(0, 0) — the same placeholder the geocoding helpers already fall back to when an address cannot be resolved (Place::getGoogleAddressArray, Place::findExistingSharedPlace).

The default sits in the base array of the array_merge, and location is not in the allow-list, so a caller can never override it.

Verified against a live stack

  • Before: the documented Create a Customer payload → 500 with the error above.
  • After: 200, with the address resolved (HOME - 123 MAIN STREET, KINGSTON, 00000, JAMAICA).
  • Control: Place::create() without a location still fails with 1364, confirming the default is what fixes it — and the same request with no place key already returned 200 both before and after.

Context

Found while making the Customers folder of the Postman collection pass (fleetbase/fleetbase#581) — this was the last blocker before all 16 requests returned 2xx.

🤖 Generated with Claude Code

POST /v1/customers accepts an optional `place` object, and the documented
payload in the Postman collection sends one. Creating it always failed:

  SQLSTATE[HY000]: General error: 1364
  Field 'location' doesn't have a default value

`places.location` is a NOT NULL POINT column with no database default, and the
attribute allow-list in resolveCustomerPlace is address-only -- a caller
cannot supply coordinates through this surface -- so Place::create was always
called without one. Every documented signup that included a place returned a
500.

Default it to Point(0, 0), the same placeholder the geocoding helpers already
fall back to when an address cannot be resolved (Place::getGoogleAddressArray,
Place::findExistingSharedPlace). The default sits in the base array of the
array_merge, and `location` is not in the allow-list, so a caller can never
override it.

Verified against a live stack: the documented Create a Customer payload now
returns 201 with the address resolved, and Place::create without a location
still fails with 1364 -- confirming the default is what fixes it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@codecov

codecov Bot commented Aug 8, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (fa37e78) to head (faf20a3).

Additional details and impacted files
@@             Coverage Diff             @@
##                main      #293   +/-   ##
===========================================
  Coverage     100.00%   100.00%           
  Complexity      9766      9766           
===========================================
  Files            521       521           
  Lines          37762     37763    +1     
===========================================
+ Hits           37762     37763    +1     
Flag Coverage Δ
backend 100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@roncodes roncodes mentioned this pull request Aug 10, 2026
@roncodes
roncodes changed the base branch from main to dev-v0.6.60 August 10, 2026 05:43
@roncodes
roncodes merged commit 6a43d21 into dev-v0.6.60 Aug 10, 2026
9 checks passed
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