feat(telegram): capture shared locations and venues #34

Merged

weiwen merged 1 commit from sandcastle/issue-23 into main

2026-07-05 21:14:16 +08:00

weiwen commented

2026-07-05 13:35:58 +08:00

Owner

Summary

Adds handling for Telegram location and venue messages in extract_message_content (src/telegram/mod.rs).

What changed:

Venue messages are matched first (before bare location), because Telegram sets both .venue() and .location() on venue messages — checking venue first yields the richer title + address representation.
Bare location pins are matched next, formatted as [Location: lat, lon].
Venue messages format as [Location: title, address (lat, lon)].
Live-location messages arrive on first share via Update::filter_message and are handled as bare locations; subsequent live-update edits come as EditedMessage events which the handler ignores — this is noted in a comment.

Key decisions:

Venue-before-location ordering is load-bearing; swapping it would produce bare coordinates for venue shares.
No temp file is returned (third tuple element is None) since locations carry no attachments.

What to review:

The format strings — confirm [Location: …] is the right representation for downstream consumers (RALPH, etc.).
Live-location behaviour: only the initial pin is captured; subsequent position updates are silently dropped. Acceptable for now but worth confirming.

Closes #23

## Summary Adds handling for Telegram location and venue messages in `extract_message_content` (src/telegram/mod.rs). **What changed:** - Venue messages are matched first (before bare location), because Telegram sets both `.venue()` and `.location()` on venue messages — checking venue first yields the richer title + address representation. - Bare location pins are matched next, formatted as `[Location: lat, lon]`. - Venue messages format as `[Location: title, address (lat, lon)]`. - Live-location messages arrive on first share via `Update::filter_message` and are handled as bare locations; subsequent live-update edits come as `EditedMessage` events which the handler ignores — this is noted in a comment. **Key decisions:** - Venue-before-location ordering is load-bearing; swapping it would produce bare coordinates for venue shares. - No temp file is returned (third tuple element is `None`) since locations carry no attachments. **What to review:** - The format strings — confirm `[Location: …]` is the right representation for downstream consumers (RALPH, etc.). - Live-location behaviour: only the initial pin is captured; subsequent position updates are silently dropped. Acceptable for now but worth confirming. Closes #23

weiwen added the

ready-for-human

label

2026-07-05 13:35:58 +08:00

weiwen commented

2026-07-05 13:38:18 +08:00

Author

Owner

Rebase onto main

weiwen added

ready-for-agent

and removed

ready-for-human

labels

2026-07-05 13:38:28 +08:00

weiwen commented

2026-07-05 18:42:51 +08:00

Author

Owner

CI was failing because pi.rs uses #[tokio::test(start_paused = true)] (for time-control tests), which requires the tokio/test-util feature — not included in full. Fixed by adding tokio = { version = "1", features = ["test-util"] } to [dev-dependencies] in Cargo.toml.

CI was failing because `pi.rs` uses `#[tokio::test(start_paused = true)]` (for time-control tests), which requires the `tokio/test-util` feature — not included in `full`. Fixed by adding `tokio = { version = "1", features = ["test-util"] }` to `[dev-dependencies]` in `Cargo.toml`.

weiwen force-pushed sandcastle/issue-23 from 99f0e42e82

CI / check (pull_request) Successful in 2m11s

Details

to 6740ec4e3c

CI / check (pull_request) Successful in 2m6s

Details

PR Triage — label changes-requested reviews / triage-review (pull_request) Failing after 1s

Details

2026-07-05 21:10:00 +08:00

Compare

weiwen merged commit 45344d10ce into main

2026-07-05 21:14:16 +08:00