Skip to content

notifications: store the push device's origin on sys_user_device and copy it into push data (ruling B on #29642, server half) #29768

Open

Description

@objectstack-fleet

domain:spec#3 · os-support-ai · session_01WGufzfgvGexKn9vLHsy89K

Filing gate: ② a maintainer ruling's server half. Ruling B on #29642 (record 6593872191, maintainer 「同意」 2026-11-03T02:26Z): "the Console sends the origin it was loaded from in RegisterDeviceRequest. The server stores it on the UserDevice row, and the push channel copies it into PushDeliveryDataSchema." The spec half is PR #29767 (#29642), which declares origin on all three schemas with the device-side members marked [PLANNED — not yet stored]. ⛔ Not a claim. Suggested-grade: p2 (inherits #29642; without it the declared origin is never stored or sent, so the mobile shell still opens a tap on the wrong server).

Business reason. A user with two saved servers in the mobile shell (objectstack-ai/mobile#173) taps a push from server B and lands on server A. The fix only works once the server stores the origin at registration and sends it back on every push. Reader: the domain:server seat, after PR #29767 merges.

What to build (measured by the #29642 dev, os-dev-report 6595041258)

  • packages/services/service-messaging/src/objects/user-device.object.ts: sys_user_device gains an origin field beside app_id / locale.
  • packages/services/service-messaging/src/device-registry.ts: the row write stores request.origin ?? null (beside app_id: request.appId ?? null, locale: request.locale ?? null), and the row read sets device.origin when present (beside if (row.locale) device.locale = …).
  • packages/runtime/src/domains/notifications.ts: no edit needed; POST /devices already passes parsed.data to registerDevice, so origin reaches the registry once the spec merges.
  • The push channel (Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041): copy the device row's origin into the push data (PushDeliveryDataSchema.origin). git grep PushDeliveryData outside packages/spec is empty today, so the copy lands there.
  • Remove the two [PLANNED — not yet stored] markers in packages/spec and flip the marker pin in push-server-origin.test.ts in the same PR (a spec-text edit inside the server PR, the declaration's own retirement).

Out of scope

Serial: after PR #29767.

Dedupe: searched "sys_user_device" origin (3 hits: #29642, #29068 closed, #29067 closed) and push origin device registry (47 hits; nearest #29042 Console registration, #29067/#29068 the closed registry build). New.

Links back: #29642, PR #29767, #29042, #29041, objectstack-ai/mobile#174.

Activity

  1. objectstack-fleet commented on Nov 3, 2026

    @objectstack-fleet
    ContributorAuthor

    domain:spec#3 · os-support-ai · session_01WGufzfgvGexKn9vLHsy89K

    Carried here from the contract review of PR #29767 (record 6595157663, PASS, three should-fix items on packages/spec/src/system/push-server-origin.ts), since this card edits that module when the [PLANNED …] markers come off:

    1. Labels follow DNS-hostname grammar: http://my_svc:3000 and a trailing-dot FQDN are refused although window.location.origin can answer them. Allow _ in a label, or name the limit in the docblock.
    2. The port arm accepts non-canonical ports (:443 on https, :80 on http, leading zeros, out of range) and the IPv6 arm accepts [:::]; tighten, or note that the Console is the one producer.
    3. The docblock should say an IPv4 host is accepted too.

    Also for the Console producer (#29042): send origin only when window.location.protocol is http: or https:; an opaque "null" origin is refused and fails the whole registration with a 400.

  2. objectstack-fleet commented on Nov 3, 2026

    @objectstack-fleet
    ContributorAuthor

    triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

    Path: none

    Triage: first-touch audit · p2 · domain:server · pm:blocked · 2026-11-03T04:52Z

    ⛔ Not a claim.

    Blocked-by: #29767


    Generated by Claude Code

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:serverDomain lane — seat card indexed by label:pm:seatenhancementNew feature or requestpm:blockedpriority:p2Medium: important, M3

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions