Departures broken

[annikahannig]

Always shows "no matching S-Bahn departurs right now"

[vibechoom]

Triage

Found it, and it's ours — a wrong pairing in the config we ship. Confirmed against the live BVG API, not just by reading code.

The message tells us more than it looks like

crates/hytte-plugin-departures/src/main.rs:468-482 renders "no matching S-Bahn departures right now" only from the BoardState::Ok | BoardState::Stale arm with items.is_empty(). A network failure or a missing station takes a different branch entirely — BoardState::Err (:473-475), whose text is prefixed "can't reach BVG: " or shows a config hint verbatim.

So the fetch succeeded, the JSON decoded cleanly, and the filter rejected every result. That rules out an outage, a broken station id, and an upstream schema change before we start.

The bug: we ship Köpenick's station id under Schöneweide's name, with Schöneweide's line filter

crates/hytte-services/src/places.rs:132-158, the DEFAULT_CONFIG written to ~/.config/trollshell/places.toml on first run:

[[place]]
name = "Schöneweide"
station = "900180001"
lines = ["S8", "S85", "S9"]

I resolved both ids against the live API:

• 900180001 → "S Köpenick/Parrisiusstr. (Berlin)" — and the only S-Bahn line calling there is S3.
• 900192001 → "S Schöneweide Bhf (Berlin)" — which is what the place is actually named after.

So we fetch Köpenick and then filter for S8/S85/S9, which never call at Köpenick. That is a structural, guaranteed-forever zero match — not flaky, not time-of-day dependent, not weather. Exactly "always shows no matching departures".

The product gate itself is fine: feed.rs:154-158 requires line.product == "suburban", and I confirmed the API still sends literally "suburban" on the wire, so that's not it either.

Why no test caught it

places.rs's unit tests (:784, :951, :982) assert station == "900180001" — they pin the literal we ship without ever cross-checking it against real line service. A test can't reasonably call the network, so this class of "the constant is self-consistently wrong" bug is invisible to it.

Also worth noting: git log shows 900180001 has been there since the feature's introduction (47a9c26), and nothing in today's #616–#639 wave touches departures, places, or the plugin. This is long-standing, not a regression from today's merges.

Severity

Medium. One widget is entirely non-functional out of the box, and silently — it reports a plausible-sounding "nothing right now" rather than "I'm misconfigured", so it looks like a quiet evening rather than a bug. Anyone who took our default config has never seen this widget work.

The check, if you want to confirm before I fix it

grep -E 'station|^lines' ~/.config/trollshell/places.toml

If that shows 900180001 with ["S8", "S85", "S9"], it's the unedited default and this is your bug.

Recommendation — two parts, and the second one matters

1. Fix the shipped default: station = "900192001". I'll also add a comment next to it naming the station in words, so the id and the name can't drift apart silently again, and reconsider whether lines/directions belong in a default at all — an empty filter shows everything passing through the station, which fails visibly useful rather than invisibly empty.
2. Your existing file won't be fixed by that. write_default_config (places.rs:329) only writes when places.toml is absent, so correcting the default helps new installs and does nothing for you. You'll need to edit ~/.config/trollshell/places.toml yourself — change station to 900192001, or drop the lines line to see everything.

Which is precisely the gap you filed #640 about 26 seconds later: there is no UI anywhere that can edit this file. I'll answer that one on its own thread.

Say the word and I'll ship part 1 — it's a two-line change plus a test that pins the id against the place name rather than just against itself.