@louis030195 Can I get a review on this one ?

I had verifies with google Calendar ICS Url and added video in description as well.

Thanks @Anshgrover23 — I checked the diff. The linked ics_calendar.rs time-window change looks good, but this PR is currently blocked by a real Ubuntu Rust CI failure.

connections_api::tests::connections_lists_ics_calendar_when_feed_enabled assumes GET /connections returns a top-level array:

let connections = payload.as_array().expect("connections array");

But the handler returns an envelope:

Json(json!({ "data": data }))

Could you update the test to read payload["data"].as_array() instead? That should fix the red test-ubuntu job.

One optional follow-up: ics_calendar_events_honors_hours_ahead_query currently only proves the route returns a JSON array; because it does not mock the ICS HTTP fetch, it can still pass with []. Stronger would be to mock a feed response or directly cover the shared ICS fetch/parser path.

@louis030195 addressed all your comments. Can I get a review on this one?

Thanks @Anshgrover23, this is in good shape. CI is green across all three OSes, feed URLs are correctly never exposed (nice that you test for it), and the local-server window test addresses my earlier follow-up well.

Two things I'd like cleaned up before I merge:

1. Don't keep two ICS parsers. The description says "share ICS parsing in screenpipe-connect", but right now the new crates/screenpipe-connect/src/ics_calendar.rs is a second copy of logic that still lives in apps/screenpipe-app-tauri/src-tauri/src/ics_calendar.rs (parse_ics_to_events, the timezone map / resolve_timezone / windows_tz_to_iana, normalize_meeting_url / extract_meeting_url, is_all_day). Two parsers will drift.

The store-reading layer genuinely can't be shared (the app goes through the Tauri store plugin, the engine reads store.bin directly), but the pure parsing should be. Please have the Tauri side call into screenpipe_connect::ics_calendar for the parse step and map the returned IcsCalendarEventItem into the app's CalendarEventItem, so there's a single source of truth for parsing.

2. Trim the unrelated Cargo.lock churn. The root Cargo.lock has a lot of unrelated bumps (windows-sys 0.52 to 0.61 across many crates, socket2 0.5 to 0.6), which looks like a stray cargo update. Please revert those so the lockfile diff only contains what this PR actually pulls in (icalendar, chrono-tz, iso8601, nom-language, phf, siphasher). Easiest is to reset Cargo.lock to main and re-run a plain cargo build / cargo check so it only adds the new transitive deps.

Once those two are done I'll merge. Appreciate the work here.

@louis030195 Can I get a review on this one ?