API Tender Legacy Action Status

Date: 2026-03-19 Sprint: Platform Cleanup Sprint 103

Scope

This document classifies the tender legacy action routes in services/api and separates route ownership from legacy outbox/event behavior.

Legacy Action Inventory

| Route | Local action | Route classification | Event behavior | Verified in-repo caller status | | --- | --- | --- | --- | --- | | POST /api/v1/tenders/legacy/propose | proposeTenderFromKes | legacy local-engine action + compatibility bridge | may emit TENDER_CREATED via emitLegacyTenderOutbox | no verified direct in-repo caller | | POST /api/v1/tenders/legacy/:id/bids | submitLegacyBid | legacy local-engine action + compatibility bridge | may emit BID_SUBMITTED | no verified direct in-repo caller | | POST /api/v1/tenders/legacy/:id/close | closeLegacyBidding | legacy local-engine action + compatibility bridge | may emit BIDDING_CLOSED | no verified direct in-repo caller | | POST /api/v1/tenders/legacy/:id/award/propose | proposeLegacyAward | legacy local-engine action + compatibility bridge | may emit AWARD_PROPOSED | no verified direct in-repo caller | | POST /api/v1/tenders/legacy/:id/award/ratify | ratifyLegacyAward | legacy local-engine action + compatibility bridge | may emit AWARD_RATIFIED | no verified direct in-repo caller |

Local-Engine vs Compatibility vs Gateway Event Emission

Legacy local-engine action

• The route handlers execute local tender compatibility logic in:
  • legacyRoutes.ts
  • engine.ts
• They do not proxy to canonical upstream tender actions through gateway.ts.

Compatibility bridge

• The /legacy/* prefix and feature-flagged enablement show that this cluster exists to preserve older tender behavior at the gateway boundary.
• It remains mounted from routes/tenders.ts after the canonical upstream tender routes.

Gateway-side legacy event emission path

• emitLegacyTenderOutbox(...) in legacyRoutes.ts posts to:
  • TENDERS_SERVICE_URL
  • LEGACY_TENDERS_OUTBOX_PATH with default /legacy/tenders/events
• This is a separate ownership concern from the route handlers themselves.
• The routes are legacy local-engine actions.
• The event emission is a gateway-side compatibility bridge into the legacy tender outbox stream.

Why These Routes Still Exist

• They preserve a historical tender action surface that has not yet been replaced by a canonical upstream tender action backend for the same flows.
• They are the gateway-side bridge for the legacy tender outbox path described in:
  • EVENT_CATALOG.md
  • EVENT_DRIVEN_ARCHITECTURE.md
• That makes them more operationally meaningful than a pure dead compatibility stub, even though I did not find verified direct in-repo callers.

What Is Still Operationally Needed

• The legacy outbox bridge is still operationally real:
  • legacy event types are documented
  • legacy_tender_events outbox behavior is documented as implemented
  • the gateway still contains the code path that appends those events toward svc-tenders
• I therefore cannot truthfully classify these routes as safely removable now.

What Can Be Reduced Later

• The route cluster can be reduced later if both become true:
  • a canonical upstream/backend owner replaces the legacy actions
  • the legacy outbox bridge is either retired or moved behind a different contract boundary

What Blocks Deeper Cleanup

• The main blocker is not gateway route shape.
• The main blocker is the still-real coupling between gateway-local legacy actions and legacy tender outbox emission.
• That coupling blocks immediate removal planning.
• It does not block further isolation.

Decision

What should remain now

• Keep the tender /legacy/* action cluster temporarily.
• Treat it as explicit compatibility bridge behavior, not canonical tender action ownership.

What should be isolated next

• Isolate the event-emission bridge further next.
• The strongest next cleanup is to separate:
  • local legacy route handling
  • gateway-side legacy outbox enqueue behavior
• That will make later removal planning much less ambiguous.

What may be removable later

• The route cluster looks removable later only after upstream/backend replacement and legacy outbox bridge replacement or retirement are decided.

Ownership Verdict

• Route ownership today: legacy local-engine action + compatibility bridge
• Event ownership today: gateway-side legacy event emission path
• Best next move: isolate into a narrower compatibility package, especially around the outbox bridge

Notes

• I found no verified direct in-repo app caller for /api/v1/tenders/legacy/*.
• That absence is not enough to remove the routes today because the event-bridge path is still documented and implemented as an operational legacy flow.