updates on the changes on warning and lat and long fixed to make it good

tests/lib/distance.test.js

@@ -35,11 +35,40 @@ describe('calculateDrivingDistance', () => {
       expect(global.fetch).not.toHaveBeenCalled();
     });
 
-    it('should accept zero coordinates, which are a real position', async () => {
+    it('should reject zero coordinates, which are only ever a failed geocode', async () => {
+      // This assertion is INVERTED from what it used to say, and the reason is
+      // that the old pair of expectations could not both hold.
+      //
+      // The case above requires a null latitude to be rejected. `Number(null)`
+      // is 0, so to any guard built on Number() a null latitude and a zero
+      // latitude are the same value — there is no implementation that rejects
+      // one and accepts the other. The old code accepted both, which is why
+      // "should reject a null latitude value" was failing on main.
+      //
+      // So it is a choice, and zero loses. Geographically (0, 0) is a real
+      // point in the Gulf of Guinea; in this product it is not reachable —
+      // Doormile operates inside the India bounding box (latitude 6.5 to 37.5,
+      // longitude 68 to 97.5, see geocodingService.isWithinIndia) and every
+      // zero coordinate ever seen in production was the residue of a geocode
+      // that failed. Accepting them cost real money: OSRM has no route to open
+      // ocean, so the Haversine fallback measured a Coimbatore pickup at
+      // roughly 11,000 km, and the backend honours that as the order's price.
       global.fetch.mockResolvedValue(osrmOk(1000, 120));
       await expect(
         calculateDrivingDistance({ latitude: 0, longitude: 0 }, { latitude: 0, longitude: 1 })
-      ).resolves.toEqual(expect.any(Number));
+      ).rejects.toThrow('Invalid coordinates');
+      expect(global.fetch).not.toHaveBeenCalled();
+    });
+
+    it('should reject a coordinate outside its own axis range', async () => {
+      // Nothing in the console checked this before. Note the limit: this
+      // catches a longitude read as a latitude only when it exceeds 90, so a
+      // transposed Coimbatore pin (11.0168, 76.9558) still passes. See
+      // lib/coords for why, and what would actually catch it.
+      await expect(
+        calculateDrivingDistance({ latitude: 94.912, longitude: 27.4728 }, IND)
+      ).rejects.toThrow('Invalid coordinates');
+      expect(global.fetch).not.toHaveBeenCalled();
     });
   });
 
@@ -61,7 +90,11 @@ describe('calculateDrivingDistance', () => {
       await calculateDrivingDistance(BLR, IND);
       const url = global.fetch.mock.calls[0][0];
       expect(url).toContain('/route/v1/driving/77.5946,12.9716;77.6245,12.9352');
-      expect(url).toContain('overview=false');
+      // The route geometry IS requested: `calculateDrivingRoute` returns a
+      // polyline for the live map preview, so this asks for overview=full with
+      // geojson geometry. It read `overview=false` until the polyline landed.
+      expect(url).toContain('overview=full');
+      expect(url).toContain('geometries=geojson');
     });
 
     it('should use the public OSRM host by default', async () => {
@@ -113,10 +146,13 @@ describe('calculateDrivingDistance', () => {
 
     it('should apply the 1.3 road multiplier to the straight-line distance', async () => {
       // One degree of latitude is 111.19 km great-circle; x1.3 = 144.5 -> 145.
+      // Measured along a meridian over India rather than from (0, 0): the
+      // arithmetic is identical at any longitude, and zero coordinates are now
+      // refused before the fetch.
       global.fetch.mockResolvedValue({ ok: false, json: async () => ({}) });
       const distance = await calculateDrivingDistance(
-        { latitude: 0, longitude: 0 },
-        { latitude: 1, longitude: 0 }
+        { latitude: 10, longitude: 77 },
+        { latitude: 11, longitude: 77 }
       );
       expect(distance).toBe(145);
     });