Skip to content

Send typed broadcast updates for survey, job, and LOI writes - #2588

Open
rfontanarosa wants to merge 6 commits into
masterfrom
rfontanarosa/typed-survey-broadcast-updates
Open

Send typed broadcast updates for survey, job, and LOI writes#2588
rfontanarosa wants to merge 6 commits into
masterfrom
rfontanarosa/typed-survey-broadcast-updates

Conversation

@rfontanarosa

@rfontanarosa rfontanarosa commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

part of #2580

Summary

  • Replaces the generic, empty-payload broadcastSurveyUpdate() with a typed broadcastUpdate() sent from the survey, job, and LOI write triggers.
  • Each FCM message now carries type (survey | job | loi), the affected entity's id, and the triggering event's commit time (eventTime); LOI updates also carry deleted.
  • Messages keep sharing one collapse key per survey, so a burst of writes (e.g. importing LOIs) still collapses into a single wake-up.
  • Newly created LOIs now have their created/lastModified serverTimestamp corrected to the actual Firestore trigger event time, replacing the client-guessed value written at import time.

Compatibility

Verified against ground-android: FirebaseMessagingService.onMessageReceived() only reads remoteMessage.from (the topic) to decide which survey to resync, and never inspects remoteMessage.data. The added fields are additive and ignored by the current app, so existing clients keep doing a full resync exactly as before. Newer clients can use the type/id hints to sync just what changed.

Replace the generic empty-payload broadcastSurveyUpdate() with a single
broadcastUpdate() that tags each FCM message with a type ('survey', 'job',
or 'loi'), the affected entity id, and the triggering event's commit time.
LOI updates also carry a deleted flag. Clients that don't inspect the
payload keep working exactly as before (full survey resync); clients that
do can use the hint to fetch just what changed instead of resyncing
everything.

Messages still share one collapse key per survey so bursts of writes (e.g.
importing LOIs) collapse into a single wake-up.
@rfontanarosa rfontanarosa self-assigned this Sep 2, 2026
@gino-m

gino-m commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

I see we opted to stick with hard-delete via FCM (push) rather than soft delete + pull? What happens if many entites are deleted (e.g. an entire survey)? Wouldn't clients get flooded with messages? Same question on batch create and write - is there a way to debounce the create and write update messages?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants