updates on the ai agents and time series prediction and updates on the api to
This commit is contained in:
@@ -26,7 +26,25 @@ const (
|
||||
maxRetries = 5
|
||||
retryDelay = 2 * time.Minute
|
||||
geoRadiusKm = 10.0
|
||||
geoMaxCount = 10
|
||||
|
||||
// How many GEO members to fetch per search.
|
||||
//
|
||||
// Raised from 10, and the reason matters. GEOSEARCH returns the N NEAREST
|
||||
// members, and eligibility (GPS freshness, availability, the active cap) is
|
||||
// applied AFTERWARDS. So any member that is near but not eligible consumes
|
||||
// one of the N slots and pushes a usable rider out of the result entirely.
|
||||
//
|
||||
// Stale members were the worst case: nothing removed a rider from the set
|
||||
// when they went off duty, so riders who finished weeks ago sat frozen near
|
||||
// the hub where most pickups originate — the nearest members there are.
|
||||
// Ten of those filled every slot, all ten were discarded, and the pool
|
||||
// collapsed to one rider who then took every order in the city.
|
||||
//
|
||||
// MilerEndDuty now removes riders (internal/milergeo.Remove), which fixes
|
||||
// it going forward. This is the defence for members ALREADY in a live
|
||||
// Redis, and for any future reason a nearby rider turns out ineligible.
|
||||
// 50 members is a cheap read and leaves room for the filters.
|
||||
geoMaxCount = 50
|
||||
|
||||
// defaultMaxActive is how many open stops one miler may hold at once.
|
||||
// Override with MILER_MAX_ACTIVE_BOOKINGS — how many parcels a rider can
|
||||
|
||||
Reference in New Issue
Block a user