Transação gRPC · DispatchergRPC transaction · DispatcherTransacción gRPC · Dispatcher

Leitura de notificaçãoNotification readLectura de notificación

A transação de escrita que marca uma notificação como lida no backend. É disparada como efeito de tocar numa notificação para abri-la — não há botão separado de "marcar como lida". O payload é mínimo: uma notificação (pelo seu identificador) e a marca de lida. É uma transação leve: reenviá-la é seguro, pois re-marcar a mesma notificação não duplica nada. Toda a construção do contrato wire vive no builder. The write transaction that marks a notification as read in the backend. It fires as a side effect of tapping a notification to open it — there's no separate "mark as read" button. The payload is minimal: one notification (by its identifier) and the read flag. It's a lightweight transaction: resending it is safe, since re-marking the same notification duplicates nothing. All wire-contract shaping lives in the builder. La transacción de escritura que marca una notificación como leída en el backend. Se dispara como efecto de tocar una notificación para abrirla — no hay un botón separado de "marcar como leída". El payload es mínimo: una notificación (por su identificador) y la marca de leída. Es una transacción liviana: reenviarla es seguro, pues re-marcar la misma notificación no duplica nada. Toda la construcción del contrato wire vive en el builder.

PúblicoAudiencePúblico

QA · Suporte · Produto · DevQA · Support · Product · DevQA · Soporte · Producto · Dev

CamadaLayerCapa

Escrita · DispatcherWrite · DispatcherEscritura · Dispatcher

RelacionadoRelatedRelacionado

Notifications · Data center

AtualizadoUpdatedActualizado

17/08/20262026-08-17

Disponível emAvailable inDisponible en BR CL ZA

O que é e quando aconteceWhat it is and when it happensQué es y cuándo ocurre

O representante de vendas recebe notificações no app (avisos, comunicados). Cada notificação pode estar não-lida ou lida. Quando o rep abre uma notificação não-lida, o app envia esta transação para o backend registrar que aquela notificação foi lida — assim a marca de "lida" acompanha o rep em qualquer dispositivo. The sales rep receives notifications in the app (alerts, announcements). Each notification can be unread or read. When the rep opens an unread notification, the app sends this transaction so the backend records that the notification was read — so the "read" mark follows the rep across any device. El representante de ventas recibe notificaciones en la app (avisos, comunicados). Cada notificación puede estar no leída o leída. Cuando el rep abre una notificación no leída, la app envía esta transacción para que el backend registre que la notificación fue leída — así la marca de "leída" acompaña al rep en cualquier dispositivo.

Uma só açãoA single actionUna sola acción A transação só faz uma coisa: marcar uma notificação como lida. Não há "marcar como não-lida" nem outra ação — abrir uma notificação já não-lida uma segunda vez não envia nada de novo. The transaction does only one thing: mark a notification as read. There's no "mark as unread" or any other action — opening an already-read notification again sends nothing. La transacción hace solo una cosa: marcar una notificación como leída. No hay "marcar como no leída" ni otra acción — abrir de nuevo una notificación ya leída no envía nada.

Fluxo de telas que disparaScreen flow that fires itFlujo de pantallas que lo dispara

As telas do caminho pertencem à feature de Notificações; aqui só situamos onde o envio acontece. O envio é um efeito de abrir a notificação — o rep não faz um toque separado para "marcar como lida":The screens along the way belong to the Notifications feature; here we only place where the send happens. The send is a side effect of opening the notification — the rep makes no separate tap to "mark as read":Las pantallas del camino pertenecen a la feature de Notificaciones; aquí solo situamos dónde ocurre el envío. El envío es un efecto de abrir la notificación — el rep no hace un toque separado para "marcar como leída":

Lista de notificaçõesNotifications listLista de notificacionesO rep abre as notificações (pelo sino no topo das telas) e vê a lista, com as não-lidas em destaque.The rep opens notifications (via the bell at the top of the screens) and sees the list, with unread ones highlighted.El rep abre las notificaciones (por la campana en la parte superior de las pantallas) y ve la lista, con las no leídas destacadas.
Tocar para abrirTap to openTocar para abrirO rep toca numa notificação para expandi-la e ler o conteúdo completo.The rep taps a notification to expand it and read the full content.El rep toca una notificación para expandirla y leer el contenido completo.
Primeiro toque numa não-lida → esta transaçãoFirst tap on an unread one → this transactionPrimer toque en una no leída → esta transacciónSe a notificação estava não-lida, esse primeiro toque dispara o envio. É este gesto que aciona a transação; o contador de não-lidas cai em seguida.If the notification was unread, that first tap fires the send. This gesture is what triggers the transaction; the unread counter drops right after.Si la notificación estaba no leída, ese primer toque dispara el envío. Este gesto es lo que activa la transacción; el contador de no leídas baja a continuación.

Só na primeira aberturaOnly on first openSolo en la primera apertura A transação parte apenas quando o rep abre uma notificação que ainda estava não-lida. Reabrir uma já lida, ou fechar/expandir de novo, não envia nada. The transaction goes out only when the rep opens a notification that was still unread. Reopening an already-read one, or collapsing/expanding again, sends nothing. La transacción sale solo cuando el rep abre una notificación que aún estaba no leída. Reabrir una ya leída, o contraer/expandir de nuevo, no envía nada.

Depois do envioAfter sendingDespués del envío

Confirmação ao repConfirmation to the repConfirmación al rep: Quando o backend aceita, o app marca a notificação como lida localmente (o destaque de não-lida some) e o contador de não-lidas do sino diminui. Não há aviso pop-up — a confirmação é a própria mudança visual da lista.When the backend accepts it, the app marks the notification read locally (the unread highlight disappears) and the bell's unread counter decreases. There's no pop-up notice — the confirmation is the list's own visual change.Cuando el backend lo acepta, la app marca la notificación como leída localmente (el destaque de no leída desaparece) y el contador de no leídas de la campana disminuye. No hay aviso pop-up — la confirmación es el propio cambio visual de la lista.
Se o envio falha / sem internetIf the send fails / offlineSi el envío falla / sin internet: A marca de lida só é aplicada se o envio for aceito. Sem conexão ou com erro, a notificação continua não-lida — não entra em fila para reenvio automático. Na próxima vez que o rep abrir a notificação com conexão, o envio acontece de novo.The read mark is applied only if the send is accepted. Offline or on error, the notification stays unread — it is not queued for automatic resend. Next time the rep opens the notification with a connection, the send happens again.La marca de leída se aplica solo si el envío es aceptado. Sin conexión o con error, la notificación queda no leída — no entra en cola para reenvío automático. La próxima vez que el rep abra la notificación con conexión, el envío ocurre de nuevo.
Reenvio é seguroResending is safeReenviar es seguro: Por ser uma transação leve, mandar de novo a mesma marca de lida não causa nenhum efeito duplicado — o backend simplesmente confirma que a notificação está lida. Abrir a mesma notificação várias vezes é inofensivo.Being a lightweight transaction, sending the same read mark again causes no duplicated effect — the backend simply confirms the notification is read. Opening the same notification several times is harmless.Al ser una transacción liviana, enviar de nuevo la misma marca de leída no causa ningún efecto duplicado — el backend simplemente confirma que la notificación está leída. Abrir la misma notificación varias veces es inofensivo.
Acompanhar o envioTracking the sendSeguir el envío: O status técnico do despacho (enviado, com erro) pode ser acompanhado na central de dados / tracking de despachos do app — útil para suporte investigar um envio.The dispatch's technical status (sent, errored) can be followed in the app's data center / dispatch tracking — useful for support to investigate a send.El estado técnico del despacho (enviado, con error) puede seguirse en el centro de datos / tracking de despachos de la app — útil para que soporte investigue un envío.

Visão técnicaTechnical overviewVisión técnica

Leitura de notificação é a transação de saída que registra no backend que uma notificação foi lida. É disparada pelo NotificationsNotifier.toggleExpand como efeito colateral de expandir uma notificação não-lida — não há UseCase de ação dedicado no widget. Uma única variante, um único serviceName (NotificationRead), sem prefixo Promo_. Está no conjunto leve (resendMayDuplicate == false). Notification read is the outbound transaction that records in the backend that a notification was read. It's fired by NotificationsNotifier.toggleExpand as a side effect of expanding an unread notification — there's no dedicated action UseCase in the widget. A single variant, a single serviceName (NotificationRead), no Promo_ prefix. It's in the lightweight set (resendMayDuplicate == false). Lectura de notificación es la transacción de salida que registra en el backend que una notificación fue leída. La dispara NotificationsNotifier.toggleExpand como efecto colateral de expandir una notificación no leída — no hay un UseCase de acción dedicado en el widget. Una única variante, un único serviceName (NotificationRead), sin prefijo Promo_. Está en el conjunto liviano (resendMayDuplicate == false).

Payload mínimoMinimal payloadPayload mínimo

Um array Notification de um único objeto com duas chaves: o sfid da notificação e dateRead: true. Nenhum cálculo, nenhum ramo condicional.A Notification array of a single object with two keys: the notification sfid and dateRead: true. No computation, no conditional branch.Un array Notification de un único objeto con dos claves: el sfid de la notificación y dateRead: true. Sin cálculo, sin rama condicional.

RPC genéricoGeneric RPCRPC genérico

Passa pelo mesmo sendTransaction de todas as transações, com o JSON no campo message e NotificationRead como serviceName discriminador.Goes through the same sendTransaction as every transaction, with the JSON in the message field and NotificationRead as the discriminating serviceName.Pasa por el mismo sendTransaction de todas las transacciones, con el JSON en el campo message y NotificationRead como serviceName discriminador.

Marca lida só em sucessoMarks read only on successMarca leída solo en éxito

O notifier só grava a leitura localmente e atualiza o badge após o ack de sucesso; falha/offline deixa a notificação não-lida (sem fila de reenvio).The notifier only persists the read locally and updates the badge after a success ack; failure/offline leaves the notification unread (no resend queue).El notifier solo persiste la lectura localmente y actualiza el badge después del ack de éxito; falla/offline deja la notificación no leída (sin cola de reenvío).

FontesSourcesFuentes BuildNotificationReadDispatcherPayloadUseCase + NotificationReadDispatcherPayloadInput + DispatcherType.notificationRead + DispatcherConectaRep.proto. O input carrega o dado como existe no domínio (o sfid + o relógio); o build() constrói todo o wire (CLAUDE.md §36). BuildNotificationReadDispatcherPayloadUseCase + NotificationReadDispatcherPayloadInput + DispatcherType.notificationRead + DispatcherConectaRep.proto. The input carries the data as it exists in the domain (the sfid + the clock); build() constructs the entire wire (CLAUDE.md §36). BuildNotificationReadDispatcherPayloadUseCase + NotificationReadDispatcherPayloadInput + DispatcherType.notificationRead + DispatcherConectaRep.proto. El input lleva el dato como existe en el dominio (el sfid + el reloj); el build() construye todo el wire (CLAUDE.md §36).

Transporte gRPCgRPC transportTransporte gRPC

DispatcherConectaRep.proto · proto3 · package mn.bat.conectarep.dispatcher. O serviço expõe um único RPC genérico — não existe mensagem por transação. TODA transação de escrita do app usa este mesmo sendTransaction; o que muda é o serviceName (discriminador) e o JSON dentro de message.The service exposes a single generic RPC — there's no per-transaction message. EVERY write transaction in the app uses this same sendTransaction; what changes is the serviceName (discriminator) and the JSON inside message.El servicio expone un único RPC genérico — no existe mensaje por transacción. TODA transacción de escritura de la app usa este mismo sendTransaction; lo que cambia es el serviceName (discriminador) y el JSON dentro de message.

sendTransactionunary

MétodoMethodMétodo

rpc sendTransaction(InboxTransactionRequest) returns (InboxTransactionReply)

path /mn.bat.conectarep.dispatcher.DispatcherConectaRepService/sendTransaction

Request · InboxTransactionRequest

endpoint: string · #1 · salesforce — type.destination.value (destino default salesforce)salesforce — type.destination.value (default salesforce destination)salesforce — type.destination.value (destino default salesforce)
serviceName: string · #2 · discriminador — sempre NotificationRead (sem prefixo Promo_)discriminator — always NotificationRead (no Promo_ prefix)discriminador — siempre NotificationRead (sin prefijo Promo_)
dateReference: string · #3 · AAAA-MM-DD do envio (formatDate(submittedAt))YYYY-MM-DD of the submission (formatDate(submittedAt))AAAA-MM-DD del envío (formatDate(submittedAt))
transactionReference: string · #4 · o sfid da notificação (correlação; = noteMappingSfid)the notification sfid (correlation; = noteMappingSfid)el sfid de la notificación (correlación; = noteMappingSfid)
username: string · #5
message: string · #6 · o payload JSON serializado (a tabela da seção 07)the JSON payload serialized (the table in section 07)el payload JSON serializado (la tabla de la sección 07)
manufacturer · model · deviceUuid · deviceVersion: string · #7–#10 · dados do dispositivo (preenchidos pelo gateway)device data (filled by the gateway)datos del dispositivo (completados por el gateway)
tid: int64 · #11 · id de transação para idempotência/replaytransaction id for idempotency/replayid de transacción para idempotencia/replay

Reply · InboxTransactionReply

status: int32 · #1 · status do ack (0 = sucesso)ack status (0 = success)status del ack (0 = éxito)
message: string · #2 · mensagem do backendbackend messagemensaje del backend
transactionId: int32 · #3 · id atribuído pelo backend (correlação)backend-assigned id (correlation)id asignado por el backend (correlación)

Envelope → Request O builder devolve um DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). O DispatcherGateway serializa payload em JSON para message (jsonEncode(envelope.payload)), copia serviceName/dateReference/transactionReference, resolve endpoint a partir de type.destination.value (aqui salesforce), preenche os campos de dispositivo e o bearer token de auth, e chama o RPC. The builder returns a DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). The DispatcherGateway serializes payload to JSON into message (jsonEncode(envelope.payload)), copies serviceName/dateReference/transactionReference, resolves endpoint from type.destination.value (here salesforce), fills in the device fields and the auth bearer token, and calls the RPC. El builder devuelve un DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). El DispatcherGateway serializa payload a JSON en message (jsonEncode(envelope.payload)), copia serviceName/dateReference/transactionReference, resuelve endpoint desde type.destination.value (aquí salesforce), completa los campos del dispositivo y el bearer token de auth, y llama al RPC.

Esta transação está no conjunto leve — resendMayDuplicate == false: um reenvio (ex.: o rep reabrir a notificação) não duplica efeito, pois re-marcar a mesma notificação como lida é idempotente no backend.This transaction is in the lightweight set — resendMayDuplicate == false: a resend (e.g. the rep reopening the notification) does not duplicate any effect, since re-marking the same notification read is idempotent on the backend.Esta transacción está en el conjunto liviano — resendMayDuplicate == false: un reenvío (p. ej. el rep reabriendo la notificación) no duplica efecto, pues re-marcar la misma notificación como leída es idempotente en el backend.

Como é disparadoHow it's firedCómo se dispara

A transação é disparada pelo NotificationsNotifier (remote-first, §36) ao expandir uma notificação não-lida. O notifier apenas reúne o sfid tocado e o relógio; o builder é o dono único da formatação de data e da montagem wire. A cascata:The transaction is fired by NotificationsNotifier (remote-first, §36) when expanding an unread notification. The notifier only gathers the tapped sfid and the clock; the builder is the sole owner of date formatting and wire assembly. The cascade:La transacción la dispara NotificationsNotifier (remote-first, §36) al expandir una notificación no leída. El notifier solo reúne el sfid tocado y el reloj; el builder es el dueño único del formateo de fecha y del armado wire. La cascada:

NotificationsNotifier.toggleExpandtap-to-expand de item não-lidotap-to-expand of an unread itemtap-to-expand de ítem no leído
- NotificationReadDispatcherPayloadInputBuildNotificationReadDispatcherPayloadUseCasemonta o wireassembles the wirearma el wire
  - devolvereturnsdevuelveDispatcherEnvelope
    - SubmitNotificationReadUseCaseDispatcherOrchestrator.dispatch
      - sendDispatcherRepository
        
        jsonEncode + authjsonEncode + authjsonEncode + authDispatcherGateway
        
        sendTransactionBackendgRPC

Marca lida só em sucessoMarks read only on successMarca leída solo en éxito toggleExpand só dispara no primeiro expand de um item não-lido (isUnread); reabrir um já lido retorna cedo, sem enviar. Só após o ack de sucesso o notifier chama MarkNotificationAsReadUseCase.execute(sfid:) (cache local), relê os cacheados e faz ref.invalidate(unreadNotificationsCountProvider) para atualizar o badge. Em falha/offline retorna sem marcar — não há registro pendente nem reenvio para este tipo (só DispatcherType.visit entra na fila). toggleExpand fires only on the first expand of an unread item (isUnread); reopening a read one returns early, sending nothing. Only after a success ack does the notifier call MarkNotificationAsReadUseCase.execute(sfid:) (local cache), re-read the cached ones and ref.invalidate(unreadNotificationsCountProvider) to refresh the badge. On failure/offline it returns without marking — there's no pending record nor resend for this type (only DispatcherType.visit is queued). toggleExpand dispara solo en el primer expand de un ítem no leído (isUnread); reabrir uno ya leído retorna temprano, sin enviar. Solo después del ack de éxito el notifier llama a MarkNotificationAsReadUseCase.execute(sfid:) (cache local), relee los cacheados y hace ref.invalidate(unreadNotificationsCountProvider) para refrescar el badge. En falla/offline retorna sin marcar — no hay registro pendiente ni reenvío para este tipo (solo DispatcherType.visit entra en la cola).

O input (dado de domínio)The input (domain data)El input (dato de dominio)

NotificationReadDispatcherPayloadInput (Freezed). O input desta transação é primitivo — o sfid da notificação + o relógio; não há entity crua a transportar nem join a fazer no builder. O relógio chega como submittedAt (via DateTimeUtils.now() no notifier).NotificationReadDispatcherPayloadInput (Freezed). This transaction's input is primitive — the notification sfid + the clock; there's no raw entity to carry nor join to do in the builder. The clock arrives as submittedAt (via DateTimeUtils.now() in the notifier).NotificationReadDispatcherPayloadInput (Freezed). El input de esta transacción es primitivo — el sfid de la notificación + el reloj; no hay entity cruda a transportar ni join a hacer en el builder. El reloj llega como submittedAt (vía DateTimeUtils.now() en el notifier).

CampoFieldCampo	TipoTypeTipo	PapelRoleRol
`noteMappingSfid`	`String`	sfid da notificação tocada — vem de `NotificationEntity.sfid` (o campo da entity chama-se `sfid`; o nome `noteMappingSfid` só existe no input/payload). Vai no payload e no `transactionReference`.sfid of the tapped notification — comes from `NotificationEntity.sfid` (the entity field is named `sfid`; the `noteMappingSfid` name exists only on the input/payload). Goes in the payload and the `transactionReference`.sfid de la notificación tocada — viene de `NotificationEntity.sfid` (el campo de la entity se llama `sfid`; el nombre `noteMappingSfid` solo existe en el input/payload). Va en el payload y en el `transactionReference`.
`submittedAt`	`DateTime`	relógio do envio (`DateTimeUtils.now()`) → `dateReference` (não vai no payload)submission clock (`DateTimeUtils.now()`) → `dateReference` (not in the payload)reloj del envío (`DateTimeUtils.now()`) → `dateReference` (no va en el payload)

Payload (`message`)

O JSON serializado no campo message do request. A tabela tem 4 colunas — Campo JSON · Tipo · Origem do Dado · Regra — e lista todas as 3 chaves que o build() emite (1 array-envelope Notification + 2 folhas). Campo, Tipo e Origem são código cru; só a Regra é prosa. Um exemplo completo está em transaction_example.json, ao lado deste doc.The JSON serialized into the request's message field. The table has 4 columns — JSON field · Type · Data source · Rule — and lists all 3 keys that build() emits (1 Notification array wrapper + 2 leaves). Field, Type and Source are raw code; only Rule is prose. A full example sits in transaction_example.json, next to this doc.El JSON serializado en el campo message del request. La tabla tiene 4 columnas — Campo JSON · Tipo · Origen del Dato · Regla — y lista las 3 claves que build() emite (1 array-envoltorio Notification + 2 hojas). Campo, Tipo y Origen son código crudo; solo la Regla es prosa. Un ejemplo completo está en transaction_example.json, junto a este doc.

Campo JSONJSON fieldCampo JSON	TipoTypeTipo	Origem do DadoData sourceOrigen del Dato	RegraRuleRegla
`Notification`	`List<Map>`	Fixo (envelope)Fixed (wrapper)Fijo (envoltorio)	array de um único objeto — o contrato envolve o item numa lista `Notification` de 1 elemento; o app nunca envia mais de uma notificação por transação.array of a single object — the contract wraps the item in a 1-element `Notification` list; the app never sends more than one notification per transaction.array de un único objeto — el contrato envuelve el ítem en una lista `Notification` de 1 elemento; la app nunca envía más de una notificación por transacción.
`Notification[].noteMappingSfid`	`String`	`input.noteMappingSfid`	o sfid da notificação (de `NotificationEntity.sfid`), renomeado para `noteMappingSfid` só aqui no payload. É a mesma string do `transactionReference` do envelope.the notification sfid (from `NotificationEntity.sfid`), renamed to `noteMappingSfid` only here in the payload. It's the same string as the envelope's `transactionReference`.el sfid de la notificación (de `NotificationEntity.sfid`), renombrado a `noteMappingSfid` solo aquí en el payload. Es la misma string del `transactionReference` del envelope.
`Notification[].dateRead`	`bool`	Fixo: `true`Fixed: `true`Fijo: `true`	sempre `true` — a transação só marca como lida; não há caminho para "não-lida". Apesar do nome sugerir uma data, o valor é um booleano.always `true` — the transaction only marks read; there's no "unread" path. Despite the name suggesting a date, the value is a boolean.siempre `true` — la transacción solo marca como leída; no hay camino para "no leída". Aunque el nombre sugiera una fecha, el valor es un booleano.

Regras de negócioBusiness rulesReglas de negocio

O que o builder decideWhat the builder decidesLo que el builder decide

Sem cálculo no builder: o build() só copia input.noteMappingSfid para o payload e para o transactionReference, e fixa dateRead: true. Não há limpeza, join, derivação nem ramo condicional.No computation in the builder: build() only copies input.noteMappingSfid into the payload and the transactionReference, and fixes dateRead: true. There's no cleanup, join, derivation or conditional branch.Sin cálculo en el builder: build() solo copia input.noteMappingSfid al payload y al transactionReference, y fija dateRead: true. No hay limpieza, join, derivación ni rama condicional.
serviceName sem prefixo: type.resolveServiceName(hasPromotion: false) — chamado com false fixo, então nunca há Promo_. O resultado é sempre NotificationRead.serviceName without prefix: type.resolveServiceName(hasPromotion: false) — called with a fixed false, so there's never a Promo_. The result is always NotificationRead.serviceName sin prefijo: type.resolveServiceName(hasPromotion: false) — llamado con false fijo, así que nunca hay Promo_. El resultado es siempre NotificationRead.
dateReference: DateTimeUtils.formatDate(dateTime: input.submittedAt) → AAAA-MM-DD. É o único campo derivado de data e vai no envelope, não no payload.dateReference: DateTimeUtils.formatDate(dateTime: input.submittedAt) → YYYY-MM-DD. It's the only date-derived field and goes on the envelope, not the payload.dateReference: DateTimeUtils.formatDate(dateTime: input.submittedAt) → AAAA-MM-DD. Es el único campo derivado de fecha y va en el envelope, no en el payload.
Leve / idempotente: resendMayDuplicate == false (conjunto {notificationRead, answerTask, priceCheck}). Um reenvio re-marca a mesma notificação como lida sem duplicar efeito.Lightweight / idempotent: resendMayDuplicate == false (set {notificationRead, answerTask, priceCheck}). A resend re-marks the same notification read with no duplicated effect.Liviana / idempotente: resendMayDuplicate == false (conjunto {notificationRead, answerTask, priceCheck}). Un reenvío re-marca la misma notificación como leída sin duplicar efecto.
Gate de disparo no notifier: só envia no primeiro expand de um item isUnread; a gravação local da leitura e o invalidate do badge acontecem só após ack.status == 0. Falha deixa a notificação não-lida.Fire gate in the notifier: sends only on the first expand of an isUnread item; the local read persist and the badge invalidate happen only after ack.status == 0. A failure leaves the notification unread.Gate de disparo en el notifier: envía solo en el primer expand de un ítem isUnread; la persistencia local de la lectura y el invalidate del badge ocurren solo después de ack.status == 0. Una falla deja la notificación no leída.

Pendências / roadmapPending / roadmapPendientes / roadmap

O que o builder/fluxo envia inerte ou fixo, documentado fiel ao estado atual do código (nunca descrito como se já existisse):What the builder/flow ships inert or fixed, documented faithfully to the current code state (never described as already existing):Lo que el builder/flujo envía inerte o fijo, documentado fiel al estado actual del código (nunca descrito como si ya existiera):

Fixo / pendenteFixed / pendingFijo / pendiente

dateRead: sempre true — não há caminho para desmarcar (marcar como não-lida). O nome sugere uma data, mas o valor é booleano.dateRead: always true — there's no path to un-mark (mark as unread). The name suggests a date, but the value is boolean.dateRead: siempre true — no hay camino para desmarcar (marcar como no leída). El nombre sugiere una fecha, pero el valor es booleano.
Sem fila offline para este tipo: no DispatcherOrchestrator, o registro pendente/reenvio está limitado a DispatcherType.visit. Um notificationRead que falhe/offline vira Error no histórico e não é auto-reenviado — a notificação continua não-lida até um novo expand com conexão. Roadmap: incluir os tipos leves no reenvio (o efeito é idempotente, então seria seguro).No offline queue for this type: in DispatcherOrchestrator, the pending-record/resend path is limited to DispatcherType.visit. A failed/offline notificationRead becomes an Error in history and is not auto-retried — the notification stays unread until a new expand with a connection. Roadmap: include the lightweight types in the resend (the effect is idempotent, so it would be safe).Sin cola offline para este tipo: en DispatcherOrchestrator, el registro pendiente/reenvío está limitado a DispatcherType.visit. Un notificationRead que falle/offline pasa a Error en el historial y no es auto-reenviado — la notificación queda no leída hasta un nuevo expand con conexión. Roadmap: incluir los tipos livianos en el reenvío (el efecto es idempotente, así que sería seguro).
Transporte: deviceUuid vai como literal provisório no gateway (pendência conhecida do Dispatcher, comum a todas as transações).Transport: deviceUuid ships as a provisional literal in the gateway (known Dispatcher pending item, common to all transactions).Transporte: deviceUuid va como literal provisional en el gateway (pendiente conocido del Dispatcher, común a todas las transacciones).

Feature relacionadaRelated featureFeature relacionada A tela e a lógica de notificações (lista, badge de não-lidas, expand) estão documentadas em Notificações. Esta transação é o único ponto de escrita dessa feature. The notifications screen and logic (list, unread badge, expand) are documented in Notifications. This transaction is that feature's only write point. La pantalla y la lógica de notificaciones (lista, badge de no leídas, expand) están documentadas en Notificaciones. Esta transacción es el único punto de escritura de esa feature.

★

MercadosMarketsMercados

A disponibilidade da transação vem do DispatcherType.notificationRead.enabledMarkets = BR/CL/ZA. AR/PY/PE existem como mercados do app (config PANGEA mínima), mas não disparam esta transação.Transaction availability comes from DispatcherType.notificationRead.enabledMarkets = BR/CL/ZA. AR/PY/PE exist as app markets (minimal PANGEA config) but don't fire this transaction.La disponibilidad de la transacción viene de DispatcherType.notificationRead.enabledMarkets = BR/CL/ZA. AR/PY/PE existen como mercados de la app (config PANGEA mínima) pero no disparan esta transacción.

BRx CLx ZAx AR— PY— PE—

disponívelavailabledisponible presente, desligadopresent, offpresente, apagado ausenteabsentausente

BRCLZA

Igual nos trêsSame across all threeIgual en los tres A transação é market-agnóstica no conteúdo: o payload (sfid + dateRead: true) e o comportamento são idênticos em BR, CL e ZA — não há campo, literal nem regra específica de mercado. The transaction is market-agnostic in content: the payload (sfid + dateRead: true) and the behavior are identical in BR, CL and ZA — no market-specific field, literal or rule. La transacción es market-agnóstica en el contenido: el payload (sfid + dateRead: true) y el comportamiento son idénticos en BR, CL y ZA — sin campo, literal ni regla específica de mercado.

AR · PY · PE Existem como mercados do app (config PANGEA mínima), mas não têm a transação de leitura de notificação — enabledMarkets lista só BR/CL/ZA. A marcação de leitura não é disparada nesses mercados. They exist as app markets (minimal PANGEA config), but have no notification-read transaction — enabledMarkets lists only BR/CL/ZA. The read marking is not fired in these markets. Existen como mercados de la app (config PANGEA mínima), pero no tienen la transacción de lectura de notificación — enabledMarkets lista solo BR/CL/ZA. La marcación de lectura no se dispara en estos mercados.