weiwen/evie

Fork 0

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 added 1 commit

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

RALPH: feat(telegram): capture shared locations and venues

CI / check (pull_request) Failing after 1m58s

Details

393040e1c8

Closes #23

## Task completed
Adds location and venue message handling to the Telegram interface so pi
can geotag notes. PRD: issue #23.

## Key decisions
- Check `msg.venue()` before `msg.location()`: a venue message has both
  fields populated; checking venue first gives the richer representation.
- Live-location messages arrive as an initial `Message` (captured here)
  then as edited-message events. `Update::filter_message` only handles
  new messages, so subsequent live updates are silently ignored — no extra
  pi turns are spawned.
- Format: bare pin → `[Location: <lat>, <lon>]`; venue → `[Location:
  <title>, <address> (<lat>, <lon>)]`. No new config or protocol changes.

## Files changed
- src/telegram/mod.rs: venue + location branches in
  `extract_message_content`, `format_location_text`,
  `format_venue_text` helpers, and three unit tests.

## Blockers / notes
- No Rust toolchain in this sandbox; CI must validate compilation and
  tests. Logic is straightforward pure-text branching.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

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 added 1 commit

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

fix: add tokio/test-util to dev-dependencies so tests compile

CI / check (pull_request) Successful in 2m11s

Details

99f0e42e82

pi.rs uses #[tokio::test(start_paused = true)] which requires the
test-util feature. The full feature set intentionally excludes it, so
tests failed to compile without an explicit dev-dependency entry.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

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