.pr_agent_accepted_suggestions - mtransitapps/mtransit-for-android GitHub Wiki

                     PR 412 (2026-08-19)                    
[reliability] Tests ignore detekt outcome
Tests ignore detekt outcome `!failure()` checks job-wide failure state rather than the detekt step, so an intervening artifact-upload failure skips tests after successful detekt while cancellation can still leave the tests eligible to run. This makes test execution diverge from the stated detekt-success condition.

Issue description

The MT tests condition uses the job-wide failure() status instead of the detekt step's outcome. This can skip tests when a report upload fails after successful detekt and does not explicitly prevent execution during cancellation.

Issue Context

Assign an id to the detekt step and gate tests on both a successful detekt outcome and a non-cancelled run, for example ${{ !cancelled() && steps.<detekt-id>.outcome == 'success' }}.

Fix Focus Areas

  • .github/workflows/mt-build.yml[77-102]
                     PR 411 (2026-08-18)                    
[performance] Canceled runs still test
Canceled runs still test Using `always()` keeps `./test_only.sh` eligible after cancellation, so superseded runs can continue expensive tests despite `cancel-in-progress: true`. Use a cancellation-aware condition such as `${{ !cancelled() }}`, which still runs tests after detekt failures.

Issue description

The MT tests step uses always(), which includes canceled runs and can waste runner capacity after a newer run supersedes the current one. Replace it with a cancellation-aware condition such as ${{ !cancelled() }} so detekt failures still do not skip tests.

Issue Context

This workflow explicitly enables cancel-in-progress, so canceled runs should not begin the full test suite.

Fix Focus Areas

  • .github/workflows/mt-build.yml[13-15]
  • .github/workflows/mt-build.yml[99-101]
                     PR 406 (2026-08-09)                    
[correctness] Null TZ becomes GMT
Null TZ becomes GMT Schedule UI code now falls back to resolving per-timestamp timezone IDs via `TimeZone.getTimeZone(...)` when a schedule/adapter timezone is absent, but null/unknown IDs silently become `GMT`, shifting formatted times and day-boundary logic. This can mislabel “today”/date separators and render incorrect departure times—often across many rows—when feeds/providers omit or emit unexpected timezone strings.

Issue description

Multiple schedule UI code paths now resolve timezones from (nullable/untrusted) timezone ID strings via TimeZone.getTimeZone(id) when a schedule-level/adapter TimeZone is missing. Because Java silently maps null/unknown IDs to GMT, this can shift formatted times and day-boundary logic (e.g., “today” labels, date separators, isSameDay checks) and produce incorrect departures without any warning when feeds/providers omit TZ metadata or emit unexpected timezone strings.

Issue Context

  • The issue is user-visible in both schedule list generation (strings + date grouping logic) and RecyclerView bind paths, so it can affect many rows.
  • The intended fallback behavior in these cases is typically the device timezone or a provider/agency timezone, not GMT.
  • This PR introduces/expands direct string-ID-to-TimeZone conversions (instead of relying on pre-resolved TimeZone objects), increasing exposure to bad/nullable input.

Fix Focus Areas

  • app-android/src/main/java/org/mtransit/android/data/UISchedule.java[573-617]
  • app-android/src/main/java/org/mtransit/android/data/UISchedule.java[931-971]
  • app-android/src/main/java/org/mtransit/android/ui/schedule/ScheduleAdapter.kt[641-685]
  • app-android/src/main/java/org/mtransit/android/ui/view/POIStatusDetailViewController.java[375-385]
[correctness] Timezone ID selection regression
Timezone ID selection regression ScheduleViewModel.setLocalTimeZoneId() now only checks the first timestamp for a timezone ID; if the first timestamp has null but a later one has a valid ID, the ViewModel falls back to the device timezone instead. This can make the schedule render in the wrong timezone even though provider data contains one.

Issue description

setLocalTimeZoneId() uses scheduleTimestamps.timestamps.firstOrNull()?.localTimeZoneId as the only timestamp-based fallback. If the first timestamp lacks TZ metadata but later ones have it, the code incorrectly falls through to the device TZ.

Issue Context

This timezone is used to compute day boundaries (startsAtInMs/endsAtInMs) and time formatting across the schedule screen.

Fix Focus Areas

  • app-android/src/main/java/org/mtransit/android/ui/schedule/ScheduleViewModel.kt[222-236]

Suggested fix

  • Restore a first-non-null search, e.g.:
  • scheduleTimestamps.timestamps.firstNotNullOfOrNull { it.localTimeZoneId }
  • Keep the existing final fallback to TimeZone.getDefault().id (and the DEBUG throw/log behavior) when no timezone exists at all.

MonTransit

⚠️ **GitHub.com Fallback** ⚠️