Subscription state must stay in sync between the notice and settings

What it is

Turn a type off from a notice, and the settings page must show off immediately; turn a type on in settings, and the next notice of that type must agree. The two surfaces are one subscription, not two switches. When they drift, people read their choice as ignored, and the next move is to skip the app and take OS permission.

This is a single source of state. It is not the claim that an unsubscribe control must exist on the notice, and not how fine types should be.

Why it happens

People treat the last operation as truth. The operation may happen on a notice, with the next check in settings—or the reverse. If each surface writes its own copy, the check fails, and trust drops from "this type listens to me" to "this app's switches are decorative." A third copy in OS channels, in-app settings, and a server list shows up as in-flight pushes: still arriving after off, or still no way to confirm after on.

Sync has to be two-way and immediate. Treating settings as master and notice-off as "mute this card" makes the in-place action a lie. Treating the notice as master while settings cache an old value makes people turn an already-off type on, thinking they are enabling it.

Studying it

Change a subscription on one surface, read it immediately on the other, then send a notice of that type and see whether the new state is honored. Insert delay, failure, and a second device.

Independent variables: change on notice vs settings, sync delay, presence of a third OS channel list. Dependent variables: time to agreement, post-change arrivals or absences, whether people then take OS permission off.

Single-device labs on a fast network understate drift. Use two devices or injected delay. Eventual consistency is not a pass—people check in the moment of the change.

Where it stops holding

Offline writes may queue locally, but the first job after reconnect is to converge, and that type must not send while still divergent. If the user changed an OS channel in system settings, the in-app page must read that change and must not write over it. On managed devices, when admin policy fights personal settings, both surfaces should show "locked by admin," not one movable and one stuck.

Applying it

• Notice menu, in-app settings, and the server list share one subscription record; a write on any surface is what the others read.
• A failed write must be reported on the surface where the action happened; do not show success and keep sending from the old list.
• Multi-device must pull before opening settings or before the next notice is shown.
• Verify: turn "social" off from a notice, open settings within a second—it should be off; send a social item—it should not arrive. Turn "social" on in settings; the next social notice's menu should show on. If any step inverts, people will go to OS permission.

Related

• Within the group: H5.09.1 Subscribe by type instead of one master switch · H5.09.2 Categories that are too fine make settings themselves a burden · H5.09.3 New types should default off, not join existing subscriptions
• Adjacent: H5.07 Push frequency · H4.05 Notification permission · H4.10 Visibility of permission state
• Search terms: settings sync · channel state · single source of subscription