[Bug]: extra_distance_km column referenced in loadRoutes.js distance filter and sort is never populated

[vipul674]

Fix

Added extra_distance_km to the load_offers insert in the order creation handler. The value comes from pricing.distanceKm which is already computed by computeOrderPricing() (either from OSRM road distance or haversine fallback).

Changes

backend/api/src/routes/orderRoutes.js (line 272)

• Insert extra_distance_km: pricing.distanceKm alongside existing freight_value, fuel_cost, toll_cost, net_profit
• The GET /api/loads endpoint already filters by .lte("extra_distance_km", maxDistance) and sorts by extra_distance_km — these will now work correctly

Closes #739

Summary by CodeRabbit

• Bug Fixes
  • Order creation now includes an additional distance-related value in the backend broadcast, helping ensure offer data is more complete and accurate.

[vipul674]

@KanishJebaMathewM I have submitted the fix. Please let me know if any changes are needed!

[github-actions]

🎉 Thank you for your contribution! Your pull request has been received and will be reviewed shortly.

If you enjoy the project, please consider giving the repository a ⭐. You can also follow my GitHub profile to stay updated on future open-source projects.

Thanks for being part of the community! 🚀

[coderabbitai]

📝 Walkthrough

Walkthrough

During order creation, the load_offers insert payload in orderRoutes.js now includes an extra_distance_km field populated from pricing.distanceKm. Previously this field was omitted, leaving it NULL for all rows.

Changes

Fix extra_distance_km population on order creation

Layer / File(s)	Summary
Add extra_distance_km to load_offers insert backend/api/src/routes/orderRoutes.js	The load_offers row created during order creation now includes extra_distance_km: pricing.distanceKm, fixing the previously NULL value that broke distance-based filtering and sorting in loadRoutes.js.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐇 A field sat empty, null and bare,
The distance column beyond repair.
One line of code, a hop, a fix —
pricing.distanceKm joins the mix!
Now filters work and sorts are true,
The bunny ships a bug fix, new. ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the bug fix and matches the main change.
Linked Issues check	✅ Passed	The change populates extra_distance_km during load offer creation as requested in #739, so the existing distance filter and sort can work.
Out of Scope Changes check	✅ Passed	The patch stays focused on the requested column population and adds no unrelated changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend/api/src/routes/orderRoutes.js`:
- Line 272: `extra_distance_km` is being populated from `pricing.distanceKm`,
which is a 2-decimal value, but the `load_offers.extra_distance_km` column is an
integer. Update the `orderRoutes` insert/mapping so the value matches the stored
type by rounding or otherwise converting it before insert, and keep the
`pricing.distanceKm` usage consistent in the relevant offer creation flow. If
decimal precision is actually needed, adjust the database schema instead of
relying on an implicit cast.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 49efd53c-cf65-4c98-95f9-731bf7beaad2

📥 Commits

Reviewing files that changed from the base of the PR and between 5bf5e07 and d6df65d.

📒 Files selected for processing (1)

• backend/api/src/routes/orderRoutes.js

[coderabbitai]

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Align extra_distance_km type with stored value (Line 272).

pricing.distanceKm is 2-decimal, but load_offers.extra_distance_km is defined as int (docs/supabase_setup.sql). This creates an implicit cast/precision loss at insert time and weakens distance filter/sort accuracy.

💡 Proposed fix

-        extra_distance_km: pricing.distanceKm,
+        extra_distance_km: Math.round(pricing.distanceKm),

(If decimal precision is required, migrate the DB column to a numeric type instead.)

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	extra_distance_km: pricing.distanceKm,
	extra_distance_km: Math.round(pricing.distanceKm),

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/api/src/routes/orderRoutes.js` at line 272, `extra_distance_km` is
being populated from `pricing.distanceKm`, which is a 2-decimal value, but the
`load_offers.extra_distance_km` column is an integer. Update the `orderRoutes`
insert/mapping so the value matches the stored type by rounding or otherwise
converting it before insert, and keep the `pricing.distanceKm` usage consistent
in the relevant offer creation flow. If decimal precision is actually needed,
adjust the database schema instead of relying on an implicit cast.

[github-actions]

🎉 Thank you for your contribution!

Your pull request has been merged successfully. We appreciate your work and look forward to your future contributions. 🚀