-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Summary
When creating a vendor via POST /Vendor/CreateClient, any submitted plantListingUrls are not saved. A follow-up PUT /Vendor/UpdateClient with the same URLs does persist them. This blocks automation and forces an extra update call after every create.
Environment
PAC stage (PAC_STAGE_API_BASE_URL=https://pac-stage.savvyotter.com)
Client: scripts in scripts/ (Python), but behavior also visible via API responses
Steps to Reproduce
Call POST /Vendor/CreateClient with a payload that includes at least one URL in plantListingUrls, e.g.:
storeName, address, state, lat, lng, storeUrl, publicEmail, publicPhone, plantListingUrls: ["https://example.com/inventory"]
Take the returned id.
Call GET /Vendor/FindById?id=.
Expected
plantListingUrls on the created vendor contains the submitted URLs.
Actual
plantListingUrls is empty ([]) after create. If you then call PUT /Vendor/UpdateClient with the same plantListingUrls, they persist and show up in FindById.
Evidence / Example
Created vendor: 3135fda2-42f9-4655-9161-1f0e7e8b324d
After CreateClient: GET /Vendor/FindById returns plantListingUrls: []
After UpdateClient with URLs: GET /Vendor/FindById returns the expected list
Impact
Breaks vendor onboarding automation (requires 2 calls instead of 1)
Causes missing listing URLs immediately after creation, so crawls can’t start reliably
Suspected Cause
Backend create path likely ignores request.PlantListingUrls (or doesn’t map it into vendor.PlantListingUris) during CreateClient persistence. UpdateClient path appears to handle it correctly.
Proposed Fix
Ensure CreateClient maps/persists request.PlantListingUrls into the vendor’s stored listing URL field(s) the same way UpdateClient does, and verify via FindById after create.
Acceptance Criteria
Creating via POST /Vendor/CreateClient with plantListingUrls results in those URLs being persisted and visible via GET /Vendor/FindById without requiring an update.