Race condition in calculateBlockTripSequence during GTFS data updates

[Bhup-GitHUB]

The calculateBlockTripSequence function in trips_helper.go performs multiple sequential database calls without a consistent snapshot of the data.

Current Flow

The function makes the following calls in order:

• GetBlockIDByTripID – fetches the block ID
• GetTripsByBlockID – fetches all trips in the block
• IsServiceActiveOnDate – checks service status (called inside a loop)
• GetStopTimesForTrip – fetches stop times (called inside a loop)

The Problem

If a GTFS data hot-swap occurs between any of these calls, each query may read from different versions of the dataset, leading to:

• Inconsistent block trip lists
• Mismatched service IDs
• Incorrect trip sequence calculations
• Potential crashes or incorrect data returned to users

Impact

This directly affects arrival/departure predictions and trip status calculations, which are core features relied on by transit riders.

Suggested Solutions

• Wrap the related database operations in a read transaction to ensure a consistent view
• Add documentation acknowledging potential staleness during updates
• Implement additional locking around GTFS database swap operations

Location

internal/restapi/trips_helper.go, lines 452–510