@zeniai/client-epic-state 5.1.45-betaDI2 → 5.1.45-betaDI3

package/lib/entity/task/taskPayload.js

@@ -53,7 +53,14 @@ const mapTaskPayloadToTask = (payload, previousTask) => ({
     depth: payload.depth !== undefined
         ? (payload.depth ?? undefined)
         : previousTask?.depth,
-    parentTaskId: payload.parent_task_id ?? undefined,
+    // `parent_task_id` may be absent on partial updates (e.g. pusher-driven
+    // task refreshes). Falling back to `undefined` there would make a real
+    // subtask look like a top-level row — breaking the depth-cap gate,
+    // `getGroupedTaskIds`'s nested-subtask filter, and the sibling
+    // `updateTasks` guard. Explicit `null` from the BE still clears it.
+    parentTaskId: payload.parent_task_id !== undefined
+        ? (payload.parent_task_id ?? undefined)
+        : previousTask?.parentTaskId,
     recurringSourceTaskId: payload.recurring_source_task_id != null
         ? payload.recurring_source_task_id
         : undefined,

package/lib/esm/entity/task/taskPayload.js

@@ -50,7 +50,14 @@ export const mapTaskPayloadToTask = (payload, previousTask) => ({
     depth: payload.depth !== undefined
         ? (payload.depth ?? undefined)
         : previousTask?.depth,
-    parentTaskId: payload.parent_task_id ?? undefined,
+    // `parent_task_id` may be absent on partial updates (e.g. pusher-driven
+    // task refreshes). Falling back to `undefined` there would make a real
+    // subtask look like a top-level row — breaking the depth-cap gate,
+    // `getGroupedTaskIds`'s nested-subtask filter, and the sibling
+    // `updateTasks` guard. Explicit `null` from the BE still clears it.
+    parentTaskId: payload.parent_task_id !== undefined
+        ? (payload.parent_task_id ?? undefined)
+        : previousTask?.parentTaskId,
     recurringSourceTaskId: payload.recurring_source_task_id != null
         ? payload.recurring_source_task_id
         : undefined,

package/lib/esm/view/taskManager/taskDetailView/epics/initializeTaskToLocalStoreEpic.js

@@ -29,7 +29,6 @@ export const initializeTaskToLocalStoreEpic = (actions$, state$) => actions$.pip
             timeSpent: task.timeSpent,
             isPrivate: task.isPrivate,
             taskGroupId: task.taskGroupIds[0],
-            depth: task.depth,
         };
         const actions = [
             saveTaskUpdatesToLocalStore({ taskDetailLocalData, taskId }),

package/lib/esm/view/taskManager/taskDetailView/taskDetailSelector.js

@@ -24,6 +24,7 @@ export const getTaskDetail = (state, taskId) => {
     let createdByUser = undefined;
     let isArchived = undefined;
     let isDeleted = undefined;
+    let depth = undefined;
     let recurringSourceTaskId = undefined;
     let snoozedUntil = undefined;
     let taskGroupId = undefined;
@@ -37,6 +38,7 @@ export const getTaskDetail = (state, taskId) => {
         const fileIdsInEntity = taskEntity?.fileIds ?? [];
         if (taskEntity != null) {
             createdByUser = getUserAndUserRole(userState, userRoleState, addressState, taskEntity.createdBy);
+            depth = taskEntity.depth;
             isArchived = taskEntity.isArchived;
             isDeleted = taskEntity.isDeleted;
             recurringSourceTaskId = taskEntity.recurringSourceTaskId;
@@ -100,6 +102,7 @@ export const getTaskDetail = (state, taskId) => {
         error: fetchStatus.error,
         version: 0,
         createdByUser,
+        depth,
         isArchived,
         isDeleted,
         recurringSourceTaskId,

package/lib/esm/view/taskManager/taskListView/taskListReducer.js

@@ -105,21 +105,34 @@ const taskList = createSlice({
             const { data, archived, completed, deleted, snoozed } = action.payload;
             draft.fetchState = 'Completed';
             draft.error = undefined;
+            // Build the nested-subtask set from the UNION of every bucket in
+            // this payload — not per-bucket. A resolved subtask can arrive in
+            // `completed` while its parent (which claims it via `subtasks`)
+            // is still in `data`; a per-bucket scan would miss the cross-tab
+            // claim and surface the subtask as a phantom top-level row in
+            // the Completed tab.
+            const nestedSubtaskIds = collectNestedSubtaskIds([
+                data,
+                completed,
+                archived,
+                deleted,
+                snoozed,
+            ]);
             // Group live tasks
-            const liveGrouped = getGroupedTaskIds(data);
+            const liveGrouped = getGroupedTaskIds(data, nestedSubtaskIds);
             draft.byTab.live = toTabData(liveGrouped);
             // Group other tabs if provided
             if (completed != null) {
-                draft.byTab.completed = toTabData(getGroupedTaskIds(completed));
+                draft.byTab.completed = toTabData(getGroupedTaskIds(completed, nestedSubtaskIds));
             }
             if (archived != null) {
-                draft.byTab.archived = toTabData(getGroupedTaskIds(archived));
+                draft.byTab.archived = toTabData(getGroupedTaskIds(archived, nestedSubtaskIds));
             }
             if (deleted != null) {
-                draft.byTab.deleted = toTabData(getGroupedTaskIds(deleted));
+                draft.byTab.deleted = toTabData(getGroupedTaskIds(deleted, nestedSubtaskIds));
             }
             if (snoozed != null) {
-                draft.byTab.snoozed = toTabData(getGroupedTaskIds(snoozed));
+                draft.byTab.snoozed = toTabData(getGroupedTaskIds(snoozed, nestedSubtaskIds));
             }
             // Copy active tab data to top-level fields
             const activeTabData = draft.byTab[draft.currentTab];
@@ -418,10 +431,17 @@ const taskList = createSlice({
                 // fetch. Mirrors backend split in task_handler.py: only
                 // `resolved` counts as completed; `done` stays Active.
                 //
-                // Subtasks travel with their parent — they appear nested under
-                // the parent row, not as standalone entries in byTab.taskIds.
-                // So we only rebucket parent tasks (tasks with no parentTaskId).
-                const isTopLevelTask = task.parentTaskId == null;
+                // "Top-level" here means: currently rendered as a standalone
+                // row in the live or completed tab (i.e. present in
+                // `byTab.<tab>.taskIds`). We use presence in byTab — NOT a
+                // `parent_task_id == null` check — so orphan subtasks (parent
+                // hidden from the customer's payload, so we render them flat)
+                // ALSO migrate between tabs on status flip. This matches the
+                // criterion `getGroupedTaskIds` uses when it builds byTab from
+                // the initial fetch — a task is nested iff a visible parent's
+                // `subtasks` array claims it, otherwise it's top-level here.
+                const isTopLevelTask = draft.byTab.live.taskIds.includes(taskId) ||
+                    draft.byTab.completed.taskIds.includes(taskId);
                 const wasCompleted = prevStatusCode === 'resolved';
                 const isCompleted = newStatusCode === 'resolved';
                 if (isTopLevelTask && wasCompleted !== isCompleted) {
@@ -518,19 +538,22 @@ const taskList = createSlice({
     },
     extraReducers: (builder) => {
         // When the entity store receives updated tasks (e.g. from task detail
-        // save, snooze/archive/unarchive, etc.), re-bucket parent tasks between
-        // the live and completed tabs based on the new status. Mirrors the
-        // backend split in task_handler.py: only `resolved` parents count as
-        // completed. Subtasks are nested under their parent row, so they
-        // never move between tabs on their own.
+        // save, snooze/archive/unarchive, etc.), re-bucket top-level tasks
+        // between the live and completed tabs based on the new status. Mirrors
+        // the backend split in task_handler.py: only `resolved` counts as
+        // completed.
+        //
+        // "Top-level" here means: currently rendered as a standalone row in
+        // the live or completed tab (i.e. present in
+        // `byTab.<tab>.taskIds`). Tasks that are nested under a parent's
+        // expanded subtask row live outside byTab.taskIds and are silently
+        // skipped by the "in-bucket" check below. This uses the same
+        // criterion as `getGroupedTaskIds` — a task is nested iff a visible
+        // parent's `subtasks` array claims it, otherwise it's top-level —
+        // so orphan subtasks (parent hidden from the customer's payload)
+        // migrate correctly on status flip via pusher / detail-save.
         builder.addCase(updateTasks, (draft, action) => {
             action.payload.forEach((taskPayload) => {
-                // Only re-bucket parents; subtasks (parent_task_id is a non-empty
-                // string) are nested under their parent row and don't move tabs.
-                if (taskPayload.parent_task_id != null &&
-                    taskPayload.parent_task_id !== '') {
-                    return;
-                }
                 const taskId = taskPayload.task_id;
                 // `TaskPayload.status` is required per the type — every producer
                 // in this repo sends it, and `mapTaskPayloadToTask` dereferences
@@ -810,7 +833,39 @@ const removeTaskIds = (draft, taskIds) => {
     removeIdsFromTabData(draft, taskIds);
     removeIdsFromTabData(draft.byTab[draft.currentTab], taskIds);
 };
-const getGroupedTaskIds = (tasks) => {
+// Collect the union of subtask ids claimed by any parent across every
+// bucket in the payload. See the callsite in `updateTaskList` for why
+// this must be cross-bucket rather than per-bucket.
+const collectNestedSubtaskIds = (buckets) => {
+    const nestedSubtaskIds = new Set();
+    buckets.forEach((bucket) => {
+        if (bucket == null) {
+            return;
+        }
+        bucket.forEach((task) => {
+            (task.subtasks ?? []).forEach((subtaskId) => nestedSubtaskIds.add(subtaskId));
+        });
+    });
+    return nestedSubtaskIds;
+};
+// A task is a "nested subtask" (hidden from the flat top-level list +
+// dropped from the tab count) iff a parent in the same payload claims
+// it via its `subtasks: [...]` array. Match this criterion exactly to
+// WC's `allSubtaskIds` union in TaskManagementPage.tsx — otherwise
+// the tab count and the visible top-level row count disagree
+// whenever the BE emits `parent_task_id` on a subtask but omits it
+// from the parent's `subtasks` array (a real inconsistency this UI
+// sees today).
+//
+// Using `parent_task_id` here would sometimes drop a task from the
+// count that WC still renders as a flat top-level row — that's the
+// bug we're fixing.
+//
+// `nestedSubtaskIds` is passed in from the caller and covers subtasks
+// claimed by parents in ANY bucket (live/completed/archived/deleted/
+// snoozed), so a subtask resolved into `completed` while its parent
+// stays in `data` is still correctly recognized as nested.
+const getGroupedTaskIds = (tasks, nestedSubtaskIds) => {
     const taskIds = [];
     const taskIdsByGroupIds = {};
     const taskIdsByAssignees = {};
@@ -824,22 +879,6 @@ const getGroupedTaskIds = (tasks) => {
         ...initialTaskIdsByDueDate,
     };
     const taskIdsByTags = {};
-    // A task is a "nested subtask" (hidden from the flat top-level list +
-    // dropped from the tab count) iff a parent in the same payload claims
-    // it via its `subtasks: [...]` array. Match this criterion exactly to
-    // WC's `allSubtaskIds` union in TaskManagementPage.tsx — otherwise
-    // the tab count and the visible top-level row count disagree
-    // whenever the BE emits `parent_task_id` on a subtask but omits it
-    // from the parent's `subtasks` array (a real inconsistency this UI
-    // sees today).
-    //
-    // Using `parent_task_id` here would sometimes drop a task from the
-    // count that WC still renders as a flat top-level row — that's the
-    // bug we're fixing.
-    const nestedSubtaskIds = new Set();
-    tasks.forEach((task) => {
-        (task.subtasks ?? []).forEach((subtaskId) => nestedSubtaskIds.add(subtaskId));
-    });
     tasks.forEach((task) => {
         const isNestedSubtask = nestedSubtaskIds.has(task.task_id);
         // Subtasks stay in every groupBy array so the UI can render them

package/lib/view/taskManager/taskDetailView/epics/initializeTaskToLocalStoreEpic.js

@@ -35,7 +35,6 @@ const initializeTaskToLocalStoreEpic = (actions$, state$) => actions$.pipe((0, o
             timeSpent: task.timeSpent,
             isPrivate: task.isPrivate,
             taskGroupId: task.taskGroupIds[0],
-            depth: task.depth,
         };
         const actions = [
             (0, taskDetailReducer_1.saveTaskUpdatesToLocalStore)({ taskDetailLocalData, taskId }),

package/lib/view/taskManager/taskDetailView/taskDetail.d.ts

@@ -47,7 +47,6 @@ export interface EditTaskLocalData {
     tagIds: ID[];
     timeSpent: string;
     type: TaskType;
-    depth?: number;
     dueDate?: ZeniDate;
     isPrivate?: boolean;
     recurringDaysOfWeek?: DayOfWeek[];

package/lib/view/taskManager/taskDetailView/taskDetailSelector.d.ts

@@ -20,6 +20,7 @@ export interface TaskDetailSelectorView extends SelectorView {
     updateFileStatusById: Record<ID, FetchStateAndError | undefined>;
     userList: UserListSelectorView;
     createdByUser?: UserAndRole;
+    depth?: number;
     isArchived?: boolean;
     isDeleted?: boolean;
     recurringSourceTaskId?: ID;

package/lib/view/taskManager/taskDetailView/taskDetailSelector.js

@@ -30,6 +30,7 @@ const getTaskDetail = (state, taskId) => {
     let createdByUser = undefined;
     let isArchived = undefined;
     let isDeleted = undefined;
+    let depth = undefined;
     let recurringSourceTaskId = undefined;
     let snoozedUntil = undefined;
     let taskGroupId = undefined;
@@ -43,6 +44,7 @@ const getTaskDetail = (state, taskId) => {
         const fileIdsInEntity = taskEntity?.fileIds ?? [];
         if (taskEntity != null) {
             createdByUser = (0, userAndRole_1.getUserAndUserRole)(userState, userRoleState, addressState, taskEntity.createdBy);
+            depth = taskEntity.depth;
             isArchived = taskEntity.isArchived;
             isDeleted = taskEntity.isDeleted;
             recurringSourceTaskId = taskEntity.recurringSourceTaskId;
@@ -106,6 +108,7 @@ const getTaskDetail = (state, taskId) => {
         error: fetchStatus.error,
         version: 0,
         createdByUser,
+        depth,
         isArchived,
         isDeleted,
         recurringSourceTaskId,

package/lib/view/taskManager/taskListView/taskListReducer.js

@@ -109,21 +109,34 @@ const taskList = (0, toolkit_1.createSlice)({
             const { data, archived, completed, deleted, snoozed } = action.payload;
             draft.fetchState = 'Completed';
             draft.error = undefined;
+            // Build the nested-subtask set from the UNION of every bucket in
+            // this payload — not per-bucket. A resolved subtask can arrive in
+            // `completed` while its parent (which claims it via `subtasks`)
+            // is still in `data`; a per-bucket scan would miss the cross-tab
+            // claim and surface the subtask as a phantom top-level row in
+            // the Completed tab.
+            const nestedSubtaskIds = collectNestedSubtaskIds([
+                data,
+                completed,
+                archived,
+                deleted,
+                snoozed,
+            ]);
             // Group live tasks
-            const liveGrouped = getGroupedTaskIds(data);
+            const liveGrouped = getGroupedTaskIds(data, nestedSubtaskIds);
             draft.byTab.live = toTabData(liveGrouped);
             // Group other tabs if provided
             if (completed != null) {
-                draft.byTab.completed = toTabData(getGroupedTaskIds(completed));
+                draft.byTab.completed = toTabData(getGroupedTaskIds(completed, nestedSubtaskIds));
             }
             if (archived != null) {
-                draft.byTab.archived = toTabData(getGroupedTaskIds(archived));
+                draft.byTab.archived = toTabData(getGroupedTaskIds(archived, nestedSubtaskIds));
             }
             if (deleted != null) {
-                draft.byTab.deleted = toTabData(getGroupedTaskIds(deleted));
+                draft.byTab.deleted = toTabData(getGroupedTaskIds(deleted, nestedSubtaskIds));
             }
             if (snoozed != null) {
-                draft.byTab.snoozed = toTabData(getGroupedTaskIds(snoozed));
+                draft.byTab.snoozed = toTabData(getGroupedTaskIds(snoozed, nestedSubtaskIds));
             }
             // Copy active tab data to top-level fields
             const activeTabData = draft.byTab[draft.currentTab];
@@ -422,10 +435,17 @@ const taskList = (0, toolkit_1.createSlice)({
                 // fetch. Mirrors backend split in task_handler.py: only
                 // `resolved` counts as completed; `done` stays Active.
                 //
-                // Subtasks travel with their parent — they appear nested under
-                // the parent row, not as standalone entries in byTab.taskIds.
-                // So we only rebucket parent tasks (tasks with no parentTaskId).
-                const isTopLevelTask = task.parentTaskId == null;
+                // "Top-level" here means: currently rendered as a standalone
+                // row in the live or completed tab (i.e. present in
+                // `byTab.<tab>.taskIds`). We use presence in byTab — NOT a
+                // `parent_task_id == null` check — so orphan subtasks (parent
+                // hidden from the customer's payload, so we render them flat)
+                // ALSO migrate between tabs on status flip. This matches the
+                // criterion `getGroupedTaskIds` uses when it builds byTab from
+                // the initial fetch — a task is nested iff a visible parent's
+                // `subtasks` array claims it, otherwise it's top-level here.
+                const isTopLevelTask = draft.byTab.live.taskIds.includes(taskId) ||
+                    draft.byTab.completed.taskIds.includes(taskId);
                 const wasCompleted = prevStatusCode === 'resolved';
                 const isCompleted = newStatusCode === 'resolved';
                 if (isTopLevelTask && wasCompleted !== isCompleted) {
@@ -522,19 +542,22 @@ const taskList = (0, toolkit_1.createSlice)({
     },
     extraReducers: (builder) => {
         // When the entity store receives updated tasks (e.g. from task detail
-        // save, snooze/archive/unarchive, etc.), re-bucket parent tasks between
-        // the live and completed tabs based on the new status. Mirrors the
-        // backend split in task_handler.py: only `resolved` parents count as
-        // completed. Subtasks are nested under their parent row, so they
-        // never move between tabs on their own.
+        // save, snooze/archive/unarchive, etc.), re-bucket top-level tasks
+        // between the live and completed tabs based on the new status. Mirrors
+        // the backend split in task_handler.py: only `resolved` counts as
+        // completed.
+        //
+        // "Top-level" here means: currently rendered as a standalone row in
+        // the live or completed tab (i.e. present in
+        // `byTab.<tab>.taskIds`). Tasks that are nested under a parent's
+        // expanded subtask row live outside byTab.taskIds and are silently
+        // skipped by the "in-bucket" check below. This uses the same
+        // criterion as `getGroupedTaskIds` — a task is nested iff a visible
+        // parent's `subtasks` array claims it, otherwise it's top-level —
+        // so orphan subtasks (parent hidden from the customer's payload)
+        // migrate correctly on status flip via pusher / detail-save.
         builder.addCase(taskReducer_1.updateTasks, (draft, action) => {
             action.payload.forEach((taskPayload) => {
-                // Only re-bucket parents; subtasks (parent_task_id is a non-empty
-                // string) are nested under their parent row and don't move tabs.
-                if (taskPayload.parent_task_id != null &&
-                    taskPayload.parent_task_id !== '') {
-                    return;
-                }
                 const taskId = taskPayload.task_id;
                 // `TaskPayload.status` is required per the type — every producer
                 // in this repo sends it, and `mapTaskPayloadToTask` dereferences
@@ -814,7 +837,39 @@ const removeTaskIds = (draft, taskIds) => {
     removeIdsFromTabData(draft, taskIds);
     removeIdsFromTabData(draft.byTab[draft.currentTab], taskIds);
 };
-const getGroupedTaskIds = (tasks) => {
+// Collect the union of subtask ids claimed by any parent across every
+// bucket in the payload. See the callsite in `updateTaskList` for why
+// this must be cross-bucket rather than per-bucket.
+const collectNestedSubtaskIds = (buckets) => {
+    const nestedSubtaskIds = new Set();
+    buckets.forEach((bucket) => {
+        if (bucket == null) {
+            return;
+        }
+        bucket.forEach((task) => {
+            (task.subtasks ?? []).forEach((subtaskId) => nestedSubtaskIds.add(subtaskId));
+        });
+    });
+    return nestedSubtaskIds;
+};
+// A task is a "nested subtask" (hidden from the flat top-level list +
+// dropped from the tab count) iff a parent in the same payload claims
+// it via its `subtasks: [...]` array. Match this criterion exactly to
+// WC's `allSubtaskIds` union in TaskManagementPage.tsx — otherwise
+// the tab count and the visible top-level row count disagree
+// whenever the BE emits `parent_task_id` on a subtask but omits it
+// from the parent's `subtasks` array (a real inconsistency this UI
+// sees today).
+//
+// Using `parent_task_id` here would sometimes drop a task from the
+// count that WC still renders as a flat top-level row — that's the
+// bug we're fixing.
+//
+// `nestedSubtaskIds` is passed in from the caller and covers subtasks
+// claimed by parents in ANY bucket (live/completed/archived/deleted/
+// snoozed), so a subtask resolved into `completed` while its parent
+// stays in `data` is still correctly recognized as nested.
+const getGroupedTaskIds = (tasks, nestedSubtaskIds) => {
     const taskIds = [];
     const taskIdsByGroupIds = {};
     const taskIdsByAssignees = {};
@@ -828,22 +883,6 @@ const getGroupedTaskIds = (tasks) => {
         ...initialTaskIdsByDueDate,
     };
     const taskIdsByTags = {};
-    // A task is a "nested subtask" (hidden from the flat top-level list +
-    // dropped from the tab count) iff a parent in the same payload claims
-    // it via its `subtasks: [...]` array. Match this criterion exactly to
-    // WC's `allSubtaskIds` union in TaskManagementPage.tsx — otherwise
-    // the tab count and the visible top-level row count disagree
-    // whenever the BE emits `parent_task_id` on a subtask but omits it
-    // from the parent's `subtasks` array (a real inconsistency this UI
-    // sees today).
-    //
-    // Using `parent_task_id` here would sometimes drop a task from the
-    // count that WC still renders as a flat top-level row — that's the
-    // bug we're fixing.
-    const nestedSubtaskIds = new Set();
-    tasks.forEach((task) => {
-        (task.subtasks ?? []).forEach((subtaskId) => nestedSubtaskIds.add(subtaskId));
-    });
     tasks.forEach((task) => {
         const isNestedSubtask = nestedSubtaskIds.has(task.task_id);
         // Subtasks stay in every groupBy array so the UI can render them

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zeniai/client-epic-state",
-  "version": "5.1.45-betaDI2",
+  "version": "5.1.45-betaDI3",
   "description": "Shared module between Web & Mobile containing required abstractions for state management, async network communication. ",
   "main": "lib/index.js",
   "module": "lib/esm/index.js",