Make trips-for-route runningLateWindow and runningEarlyWindow configurable

[cotishq]

Problem

trips-for-route currently hardcodes the activity window used to include active trips around the current time:

• runningLateWindow = 30 minutes
• runningEarlyWindow = 10 minutes

These values are defined directly in trips_for_route_handler.go (line 66) with a TODO noting that Maglev should support config for these values like the Java OBA server.

Because the values are hardcoded, agencies cannot tune how aggressively Maglev includes trips that are slightly late, slightly early, or running past midnight.

---

Scenario

A transit agency wants trips-for-route to behave differently from the current defaults:

• Agency operates frequent service with longer real-world delay tails
• Vehicles commonly remain relevant beyond the fixed 30-minute late window
• Or the agency wants stricter matching and does not want trips included 10 minutes early

At the moment, changing this behavior requires a code change instead of a configuration change.

---

Impact

This affects behavioral parity and deployability:

• Maglev cannot yet match agency-specific or Java OBA-like tuning for trips-for-route
• Operators cannot adjust trip visibility behavior without rebuilding the server
• Small differences in these windows can change which trips appear active near schedule boundaries and after midnight

---

Current Code

In trips_for_route_handler.go (line 66), the handler currently uses:

• runningLateNanos = 30 minutes
• runningEarlyNanos = 10 minutes

There is also a TODO indicating these values should come from configuration.

---

Suggested Fix

Add configuration for these windows while preserving current behavior as defaults.

Possible Approach

• Add running-late-window and running-early-window fields to config
• Keep defaults at:
  • 30m (late window)
  • 10m (early window)
• Wire these values through application config into the REST handler
• Update tests to cover:
  • Default values
  • Custom configured values
• Document the new config fields in the README / config schema

[cotishq]

@aaronbrethorst whats your opinion on this , should i start working on this issue ?

[tejasva-vardhan]

Hello @cotishq, I am a fellow contributor here! I’ve been digging into the codebase for some parity fixes recently (#798) and I think this is a great catch.

Hardcoding those windows definitely limits how different agencies can tune Maglev. Your plan for config.json is solid. One small suggestion—maybe we can handle the defaults in internal/appconf/json_config.go? It would keep the handler logic clean since we wouldn't have to check for zero/nil values on every request.

Also, adding a quick check in Validate() to prevent negative windows would be a nice safety touch. Looking forward to your PR!

[cotishq]

Thanks @tejasva-vardhan , that’s helpful. Handling the defaults in internal/appconf/json_config.go makes sense to me too. That keeps the request path simple and makes the behavior consistent whether values come from JSON or flags.

I also agree on validation. I’m planning to reject negative values and keep the current behavior as the default if the fields are omitted. That should make the change low-risk while still giving agencies a clean tuning knob.

[tejasva-vardhan]

@cotishq Sounds good. Putting defaults in json_config.go plus rejecting negatives in Validate() matches what I had in mind too. If you want a second pair of eyes on the PR when it’s up, feel free to tag me.