@feedmepos/mf-order-setting 0.0.85 → 0.0.86

package/src/views/order-settings/delivery/integrated-delivery/LinemanSetting.vue

@@ -1,5 +1,5 @@
 <script setup lang="ts">
-import { computed, type PropType, reactive } from 'vue'
+import { computed, onUnmounted, type PropType, reactive, watch } from 'vue'
 
 import type { FdoLinkedDelivery } from '@feedmepos/core/entity'
 import { type FdoLinemanSettings } from '@entity'
@@ -10,6 +10,7 @@ import { remoteOrderApi } from '@/api/remoteOrder'
 import { useCoreStore, useI18n } from '@feedmepos/mf-common'
 import { useSnackbarFunctions } from '@/components/snackbar'
 import IntegratedDelivery from './IntegratedDelivery.vue'
+import IntegrationIdentityDetails from './IntegrationIdentityDetails.vue'
 import { clone } from '@/helpers/object'
 
 export interface LinemanDeliveryData {
@@ -87,20 +88,151 @@ const { currentRestaurant } = useCoreStore()
 const { showSuccess, showError } = useSnackbarFunctions()
 const { isLoading, startAsyncCallWithErr } = useLoading()
 
-async function syncMenu() {
-  await startAsyncCallWithErr(async () => {
-    const partnerId = data.integrated.partnerID
-    const catalogId = data.integrated.catalogId
-    const restaurantId = currentRestaurant.value?._id
+// Lineman has no generated integration id: the FeedMe restaurant id IS the
+// `storeId` we register with them and the one their menu/order webhooks carry.
+const restaurantId = computed(() => currentRestaurant.value?._id ?? '')
+
+// One block support can paste into the Lark thread in a single press. Composed
+// here rather than in the card because platform, restaurant and status are the
+// caller's to know. It is also the snapshot that survives the next sync, which
+// nulls `menuSyncError` and replaces `menuSyncRequestId`.
+const supportSummary = computed(() => [
+  { label: t('order.platform'), value: 'LINE MAN' },
+  { label: t('order.restaurantId'), value: restaurantId.value },
+  { label: t('order.status'), value: data.integrated.status },
+  { label: t('order.lastSync'), value: data.integrated.lastSynchronize },
+  { label: t('order.lastAcceptedSyncRequestId'), value: data.integrated.menuSyncRequestId }
+])
+
+// A sync writes its outcome onto the setting either way: PROCESSING with a
+// fresh menuSyncRequestId when LINE MAN accepts the request, FAILED with the
+// rejection body when it does not. Neither reaches this component - the
+// rejected call only surfaces as a snackbar - so read the record back instead
+// of mirroring the one branch we happened to take.
+//
+// Only the sync-owned fields are taken. The rest of `integrated` is bound to
+// the form, which may hold edits the merchant has not saved yet.
+//
+// Reads race each other: a poll issued before a re-sync can resolve after that
+// sync's own read and roll the panel back to the previous attempt, so only the
+// newest read is allowed to write.
+let latestRead = 0
+// `stopPolling` only clears a pending timer, so a read already in flight at
+// unmount has to check for itself before touching state or queueing another
+// poll - otherwise navigating away mid-read leaves the loop running.
+let isActive = true
+
+async function readSyncState() {
+  const read = ++latestRead
+
+  try {
+    const setting = await remoteOrderApi.integratedDelivery.readLineman(restaurantId.value)
+    if (!isActive || read !== latestRead || !setting) return
+
+    data.integrated = {
+      ...data.integrated,
+      status: setting.status,
+      menuSyncError: setting.menuSyncError,
+      menuSyncRequestId: setting.menuSyncRequestId,
+      lastSynchronize: setting.lastSynchronize,
+      updatedAt: setting.updatedAt
+    }
+    emits('update:model-value', { manual: data.manual, auto: data.integrated })
+  } catch (error) {
+    // Any sync result has already been reported. A failed read-back only leaves
+    // the diagnostics stale, which the next poll or reload fixes, so do not
+    // bury that result under a second error - and do not stop the polling loop,
+    // which would turn one dropped request into a permanently stale panel.
+    console.error('Failed to read Lineman setting', error)
+  }
+}
+
+// PROCESSING is not a resting state: LINE MAN confirms the sync over a webhook
+// that lands on the backend, so the record moves to SUCCESS/FAILED without this
+// panel hearing about it. Keep asking until it settles, otherwise an error that
+// arrives a minute after the sync - the case these diagnostics exist for - is
+// invisible until a reload.
+const SYNC_POLL_INTERVAL_MS = 10_000
+// LINE MAN has never confirmed a sync back to us, or it has and the webhook was
+// rejected. Either way further polling will not learn anything, so stop rather
+// than hold an open tab on a permanent timer. A reload re-arms the watcher.
+const SYNC_POLL_TIMEOUT_MS = 5 * 60_000
+
+let pollTimer: ReturnType<typeof setTimeout> | null = null
+let pollDeadline = 0
+
+function stopPolling() {
+  if (!pollTimer) return
+  clearTimeout(pollTimer)
+  pollTimer = null
+}
+
+function queueNextPoll() {
+  // Chained rather than setInterval: a slow read cannot stack requests on top
+  // of each other.
+  pollTimer = setTimeout(async () => {
+    pollTimer = null
+    await readSyncState()
+
+    if (isActive && data.integrated.status === 'PROCESSING' && Date.now() < pollDeadline) {
+      queueNextPoll()
+    }
+  }, SYNC_POLL_INTERVAL_MS)
+}
+
+function startPolling() {
+  stopPolling()
+  pollDeadline = Date.now() + SYNC_POLL_TIMEOUT_MS
+  queueNextPoll()
+}
 
-    if (!partnerId || !restaurantId) {
-      showError('Missing Lineman partnerID or restaurantId')
+// `immediate` so a panel opened while a sync is still in flight picks it up,
+// not only one that watched the sync start.
+watch(
+  () => data.integrated.status,
+  (status) => {
+    if (status !== 'PROCESSING') {
+      stopPolling()
       return
     }
+    if (!pollTimer) startPolling()
+  },
+  { immediate: true }
+)
+
+onUnmounted(() => {
+  isActive = false
+  stopPolling()
+})
+
+async function syncMenu() {
+  const partnerId = data.integrated.partnerID
+  const catalogId = data.integrated.catalogId
+
+  if (!partnerId || !restaurantId.value) {
+    showError('Missing Lineman partnerID or restaurantId')
+    return
+  }
+
+  await startAsyncCallWithErr(async () => {
+    try {
+      await remoteOrderApi.integratedDelivery.syncLinemanMenu(
+        partnerId,
+        restaurantId.value,
+        catalogId
+      )
 
-    await remoteOrderApi.integratedDelivery.syncLinemanMenu(partnerId, restaurantId, catalogId)
+      showSuccess(t('order.syncMenuSuccess'))
+    } finally {
+      // Inside the callback so the button stays disabled until the panel has
+      // caught up, and in `finally` so a rejected sync refreshes too.
+      await readSyncState()
 
-    showSuccess(t('order.syncMenuSuccess'))
+      // Re-syncing while already PROCESSING leaves the status unchanged, so the
+      // watcher does not fire and the window would still be the previous
+      // attempt's - possibly already expired. This attempt gets a fresh one.
+      if (data.integrated.status === 'PROCESSING') startPolling()
+    }
   })
 }
 </script>
@@ -112,6 +244,7 @@ async function syncMenu() {
     :can-use-auto-delivery-integration="canUseAutoDeliveryIntegration"
     :show-test-order-actions="false"
     :sync-menu-loading="isLoading"
+    hide-menu-sync-error-tooltip
     @update:model-value="updateDataPass"
     @sync-menu="syncMenu"
   >
@@ -123,5 +256,23 @@ async function syncMenu() {
         value=""
       />
     </template>
+    <!-- `menuSyncError` comes from the slot rather than `data.integrated` so the
+         card shows the same item-name-resolved string the tooltip used to, and
+         the tooltip itself is suppressed to keep one copy of the error. -->
+    <template #integration-details="{ menuSyncError }">
+      <IntegrationIdentityDetails
+        hide-identity
+        :guidance="t('order.linemanSyncDiagnosticsGuidance')"
+        :reference-id="data.integrated.menuSyncRequestId"
+        :reference-label="t('order.lastAcceptedSyncRequestId')"
+        :message="menuSyncError"
+        :message-label="t('order.menuSyncError')"
+        show-empty-message
+        :support-summary="[
+          ...supportSummary,
+          { label: t('order.menuSyncError'), value: menuSyncError }
+        ]"
+      />
+    </template>
   </IntegratedDelivery>
 </template>