Laravel Notification Zapmizer Laravel Package

Product Decisions This Supports

• Message sync semantics for Laravel/PHP integrations with Zapmizer: the 0.4.x line adds syncMessages(), which returns the messages recorded after the cursor. 0.4.1 is documentation-only and corrects the 0.4.0 wording: messages arriving during a reconnection sync are included, but an edit to a message that already existed is not returned (Zapmizer paginates by primary key). The 0.4.0 text claiming “edited, deleted” was wrong. Deletions are likewise not delivered as sync deltas.
• Roadmap impact — inbox and history features: this supports incremental ingestion of new messages, backfill after downtime, and reconnection catch-up. It does not support change-data-capture semantics (edit history, tombstones, deletion propagation, edit-aware audit trails) through sync alone; those require explicit refetch-by-ID or a separate reconciliation path.
• Build vs. buy: adopt when the product needs cursor-based incremental message ingestion plus the media handling from 0.3.x in a Laravel app against Zapmizer. Do not adopt assuming sync gives edit/delete awareness. Risk is low: 0.4.1 changes no code.
• Upgrade prioritization / spec correction: 0.4.1 requires no code change beyond being on 0.4.0, but the corrected semantics may invalidate assumptions in existing designs, acceptance criteria, or customer promises. Treat it as a spec correction and audit any feature that assumed edits or deletions were synced.
• Data integrity and UX decisions: product must define behavior for stale message bodies (edited messages showing old text), messages that persist after upstream deletion, duplicate/overlap handling on reconnection sync, and the cadence of refetch or full reconciliation.

When to Consider This Package

• Consider adoption when the product is a Laravel/PHP application integrating with Zapmizer and needs cursor-based incremental message sync plus a maintained client for media interactions (typed 422/429 exceptions and rate-limit-aware awaitMedia() from 0.3.1).
• Strong fit when append-only ingestion of new messages is sufficient and it is acceptable that edits and deletions of existing messages are picked up only via explicit refetch-by-ID or periodic reconciliation.
• Reasonable fit when the team wants vendor-aligned behavior instead of hand-rolled cursor and error handling, and accepts the primary-key pagination model.
• Look elsewhere, or plan an added layer, if the product needs edit history, deletion/tombstone propagation, provider-agnostic messaging/media abstraction, a non-Laravel/PHP stack, or a broader multi-channel integration layer.
• Before adoption, verify: cursor and pagination semantics, duplicate/overlap behavior across reconnection syncs, ordering guarantees, how edited messages are detected and refetched, retention expectations for deleted messages, and whether 0.4.0 introduced changes beyond syncMessages() (0.4.1 only corrects documentation).
• Pin and read the right docs: 0.4.1 is documentation-only; use the corrected 0.4.1 description of syncMessages() rather than the 0.4.0 text.

How to Pitch It (Stakeholders)

For executives: 0.4.1 is a documentation-only release that corrects the description of the message sync capability introduced in 0.4.0. No code changes and no upgrade risk, but it changes what we should promise: sync delivers new messages after a cursor, not edits or deletions of messages that already exist. Worth a short review of any feature spec or customer commitment that assumed otherwise, and a decision on how we reconcile edited or deleted messages.

For engineering: 0.4.1 corrects the docs for syncMessages(): it returns messages recorded after the cursor; messages arriving on a reconnection sync are included, but edits to pre-existing messages are not returned because Zapmizer paginates by primary key — 0.4.0's “edited, deleted” wording was incorrect. There are no code changes in 0.4.1. Review catch-up and refresh logic, and add explicit refetch-by-ID or periodic reconciliation if edit/delete awareness is required. The 0.3.1 media behavior (MediaRejectedException 422 with reason(), MediaRateLimitedException 429 with retryAfter(), and awaitMedia() waiting on Retry-After) is unchanged.