Sync status

Ang sync status page (/calendar/sync-status) ay ang history view para sa bawat calendar sync run na ginawa ng Zellbox para sa iyong account. Ito ang puntahan kapag may mukhang mali: "tumakbo ba ang periodic sync?", "bakit hindi lumabas ang event kahapon?", "ano ang kakablock lang ng safety guard?". Marating ito sa:

• ang label na Na-sync N na nakalipas sa pahinang Kalendaryo,
• ang link na Tingnan ang buong sync history → sa isang sync- quarantine banner,
• ang link na Tingnan ang sync history → sa ilalim ng Google Calendar sa pahinang Google Sync (/google-sync), o
• sa pamamagitan ng direktang pagbukas ng /calendar/sync-status.

Pagpili ng time window

Ang filter card sa itaas ng pahina ay pinapaliit kung anong run ang nakalista. Pre-set ng quick-range chip ang mga karaniwang window; pinapadali ng From / To datetime input na i-fine-tune ang alinmang panig; tinatanggal ng Clear ang parehong bound. Sinasabi ng counter na {n} runs in window sa kanan kung ilang sync job ang tumutugma sa kasalukuyang filter.

Chip	Window
Huling oras	Ngayon − 60 min
Huling 24 h (default)	Ngayon − 24 h
Huling 7 araw	Ngayon − 7 araw
Huling 30 araw	Ngayon − 30 araw
Lahat	Walang bounds — naka-cap sa 100 resulta, pinakabago muna

Ang bawat row ay status card:

✓ Succeeded · Refresh · 2 min ago · 24s · 12 calendars · 1,247 events touched (812 added · 311 updated · 124 cancelled)
  12 done
  ▸ Show calendar details

Ang kulay na tuldok + ang status chip ay nagsasabi sa iyo ng kinalabasan nang mabilis:

Estado	Kahulugan
Succeeded (green)	Lahat ng calendar branch ay umupo.
Partial (amber)	Ilang branch ay naging tagumpay, ilan ay nag-error. Palawakin ang row para makita kung alin. Nagpapakita rin ang row ng "held for review" count kapag nag-quarantine ang safety guard ng cohort.
Failed (red)	Lahat ng branch ay nag-error. Karaniwang ibig sabihin nag-expire ang OAuth token — muling ikonekta ang Google.
Queued / Running (blue)	Lumilipad ang job. Awtomatikong nag-pi-poll ang pahina habang non-terminal ang anumang job.

Ipinapakita rin ng row ang trigger source:

• Initial connect — ang post-OAuth seed job na tumatakbo minsan kapag ikinonekta mo ang Google sa unang beses.
• Manual refresh — na-click mo ang Refresh button sa pahinang Kalendaryo.
• Auto-sync — ang 5-minutong scheduled tick.
• New calendar added — nag-tsek ka ng bagong calendar sa pahinang Google Sync; nagpapatakbo ang Zellbox ng one-off sync para magbinhi nito.

Sa ilalim ng headline, may pangalawang linya na nagbubuod kung paano umaabante ang mga calendar branch ng run — kapaki-pakinabang sa pagkilala ng in-flight na tick mula sa natapos nang hindi pinalalawak ang row:

8 done · 2 running · 2 queued

Kung wala pang naitalang per-calendar progress (ang safety net para sa unang sandali ng bagong run), ang linya ay nagbabasa ng No per-calendar progress recorded yet.

Mga per-calendar na detalye

I-click ang row → palawakin para makita ang per-calendar na breakdown. Bawat branch ay may sariling status icon + counts:

✓ primary               · 234 events synced
✓ Dr. Smith — Cardio    · 89 events synced
⚠ Shared — Pediatrics   · 47 cancellations held for review — [Approve]
✗ Dr. Lee — Dermatology · error: token expired (re-connect required)

Pinag-uuri ang mga branch para nauuna ang quarantined at errored entries — ang mga bagay na kailangan ng atensyon mo ay nasa itaas.

Pagsusuri ng quarantined na cancellation

Kapag pumutok ang safety guard, makakakita ka ng dilaw na banner sa pahinang Dashboard + Kalendaryo:

⚠ 47 na event cancellation sa 1 calendar ang hinold para sa pagsusuri ng safety guard.

Para malutas:

1. I-click ang Review sa banner, o buksan ang pahinang Sync status.
2. Palawakin ang row na may quarantined na branch.
3. Basahin ang diagnostic: "X (na) would-be cancellation · mirror size Y · dahilan". Ipinapaliwanag ng dahilan kung bakit pumutok ang guard:
   • on-seed — mga kanselasyon sa initial seed (kahina-hinala; ang bagong mirror ay hindi dapat may kakanselahin).
   • abs-limit — mahigit 25 kanselasyon sa isang run.
   • pct-limit — mahigit 20% ng mirror ang kakanselahin.
4. I-click ang View held events → para palawakin ang per-event list (tingnan sa ibaba). I-scan para kumpirmahin na mukhang lehitimong bulk cleanup ang mga event sa halip na isang connection mishap.
5. I-click ang Approve cancellations. Ang confirmation dialog ay may tatlong block:
   • Ano ang mangyayari: ang bilang + ang calendar id.
   • Bakit pumutok ang guard: paliwanag na specific sa dahilan (parehong distinction ng on-seed / pct-limit / abs-limit mula sa hakbang 3, ngunit naka-frame para sa desisyon ng operator).
   • Safety net: ang bawat event na malapit nang kanselahin ng Zellbox ay awtomatikong nasa-snapshot sa backup table muna. May 90 araw kang ibalik ang alinman sa kanila nang isa-isa mula sa Recovery — ang mga naibalik na event ay bumabalik bilang Zellbox-only at hindi muling itinutulak sa Google nang awtomatiko.
6. I-click ang Apply cancellations. Lumilikha ang Zellbox ng bagong single-calendar sync job na binu-bypass ang guard para sa calendar na iyon. Nag-a-apply ang mga kanselasyon; nakikita mo ang bypass job sa itaas ng kasaysayan.

Kung mas gusto mong hindi aprubahan — halimbawa, pinaghihinalaan mong sinadyang tinanggal ng may-ari ng shared calendar ang lahat — iwan ang quarantine. Awtomatikong lilinisin ng susunod na clean sync ang slot.

Drill-down ng mga hinold na event

Sa ilalim ng diagnostic line, ang View held events → ay lazy-load ng bawat event na tinanggihan ng safety guard para sa isang branch na iyon. May pamagat, start time (sa workspace time zone), naka-link na customer name kapag mayroon, at preview ng paglalarawan ang bawat row.

Pinag-uuri ng listahan ang dalawang uri ng row:

• Matched event — mayroon pa ring mirror row ang Zellbox para sa event. Naka-render bilang puting card.
• Ghost tombstone — iniulat ng Google ang status: cancelled para sa event na wala sa aming mirror (halos palaging: kanselasyon na nangyari bago ikinonekta ang Zellbox sa calendar na ito). Naka-render bilang kulay-abong card na may italic na "Google tombstone (walang Zellbox record)" na note.

Ipinapakita ng summary line sa itaas ng listahan ("41 matched · 313 ghosts · total 354") ang breakdown kaya napapababa ang nakakatakot na aggregate number — kadalasan ang malaking bahagi ng "354 na kanselasyon" ay ghost na walang totoong epekto.

Mga branch na quarantined bago naglunsad ang feature na ito ay nagpapakita lang ng aggregate count (walang per-event row sa audit log). Naglalabas ang empty state ng button na Recover details from Google na muling kumukuha ng cohort mula sa Google sa parehong seed window at sumusulat ng kulang na audit row sa hindi pa nababalikang paraan. Pagkatapos itong tumakbo, nagpapatakbo nang normal ang listahan.

Saan nagpoprotekta ang guard

Umiiral ang safety guard para maiwasan na ang isang sync hiccup ay tahimik na nagkansela ng maraming event. Mga konkretong failure mode na sinasaklaw nito:

• Bumalik ang Google ng corrupt page kung saan maraming totoong event ang lumalabas bilang status: cancelled.
• Ang token swap o pagbabago ng shared-calendar permission ay nagpapaisip sa Zellbox na walang laman ang buong calendar.
• May bug sa aming parsing na nagmamarka sa malusog na event bilang cancelled.

Sa alinmang kaso, tumatanggi ang guard sa buong batch at hinihiling sa iyong kumpirmahin bago i-apply.