@zeniai/client-epic-state 5.2.51-betaRD1 → 5.2.51

package/lib/view/expenseAutomationView/epics/jeSchedule/fetchFailedJePostingsEpic.d.ts

@@ -1,20 +0,0 @@
-import { ActionsObservable, StateObservable } from 'redux-observable';
-import { Observable } from 'rxjs';
-import { updateJESchedules, updateJESchedulesDetails } from '../../../../entity/jeSchedules/jeSchedulesReducer';
-import { clearAll } from '../../../../rootActions';
-import { RootState } from '../../../../rootStateTypes';
-import { ZeniAPI } from '../../../../zeniAPI';
-import { fetchFailedJePostings, fetchFailedJePostingsFailure, fetchFailedJePostingsSuccess, initializeJeScheduleLocalData } from '../../reducers/jeSchedulesViewReducer';
-export type ActionType = ReturnType<typeof clearAll> | ReturnType<typeof fetchFailedJePostings> | ReturnType<typeof fetchFailedJePostingsFailure> | ReturnType<typeof fetchFailedJePostingsSuccess> | ReturnType<typeof initializeJeScheduleLocalData> | ReturnType<typeof updateJESchedules> | ReturnType<typeof updateJESchedulesDetails>;
-/**
- * Fetches every currently-failing posting for the tenant, on its own endpoint and with no window.
- *
- * Sends no query at all. The endpoint takes an optional `expected_post_start_date` floor and the
- * client deliberately omits it: a failure is outstanding work until someone resolves it, whatever
- * month it belongs to, and windowing this list is exactly what kept older failures off the only
- * screen that can resolve them.
- *
- * `switchMap`, not `mergeMap`: there is one list per tenant, so a second trigger supersedes the
- * first rather than racing it.
- */
-export declare const fetchFailedJePostingsEpic: (actions$: ActionsObservable<ActionType>, _state$: StateObservable<RootState>, zeniAPI: ZeniAPI) => Observable<ActionType>;

package/lib/view/expenseAutomationView/epics/jeSchedule/fetchFailedJePostingsEpic.js

@@ -1,44 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.fetchFailedJePostingsEpic = void 0;
-const rxjs_1 = require("rxjs");
-const operators_1 = require("rxjs/operators");
-const jeSchedulesReducer_1 = require("../../../../entity/jeSchedules/jeSchedulesReducer");
-const responsePayload_1 = require("../../../../responsePayload");
-const rootActions_1 = require("../../../../rootActions");
-const jeSchedulesViewReducer_1 = require("../../reducers/jeSchedulesViewReducer");
-/**
- * Fetches every currently-failing posting for the tenant, on its own endpoint and with no window.
- *
- * Sends no query at all. The endpoint takes an optional `expected_post_start_date` floor and the
- * client deliberately omits it: a failure is outstanding work until someone resolves it, whatever
- * month it belongs to, and windowing this list is exactly what kept older failures off the only
- * screen that can resolve them.
- *
- * `switchMap`, not `mergeMap`: there is one list per tenant, so a second trigger supersedes the
- * first rather than racing it.
- */
-const fetchFailedJePostingsEpic = (actions$, _state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(jeSchedulesViewReducer_1.fetchFailedJePostings.match), (0, operators_1.switchMap)(() => zeniAPI
-    .getJSON(`${zeniAPI.apiEndPoints.accountMicroServiceBaseUrl}/1.0/expenses_automation/failed_je_postings`)
-    .pipe((0, operators_1.switchMap)((response) => {
-    if (!(0, responsePayload_1.isSuccessResponse)(response) || response.data == null) {
-        return (0, rxjs_1.of)((0, jeSchedulesViewReducer_1.fetchFailedJePostingsFailure)(response.status));
-    }
-    const failedJeSchedules = response.data.failed_je_postings?.je_schedules ?? [];
-    const failedScheduledJournalEntries = response.data.failed_je_postings?.scheduled_journal_entries ?? [];
-    // Order matters and matches fetchJeSchedulesEpic: updateJESchedules fans out to the
-    // vendor / account / class / user entities, updateJESchedulesDetails then attaches the
-    // journal entries, and only then can initializeJeScheduleLocalData read them back.
-    return (0, rxjs_1.from)([
-        (0, jeSchedulesReducer_1.updateJESchedules)(failedJeSchedules),
-        (0, jeSchedulesReducer_1.updateJESchedulesDetails)(failedJeSchedules, failedScheduledJournalEntries),
-        (0, jeSchedulesViewReducer_1.initializeJeScheduleLocalData)(failedJeSchedules),
-        (0, jeSchedulesViewReducer_1.fetchFailedJePostingsSuccess)(failedJeSchedules),
-    ]);
-}), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, jeSchedulesViewReducer_1.fetchFailedJePostingsFailure)((0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'fetch failed JE postings REST API call errored out' +
-    JSON.stringify(error))))), 
-// A tenant switch clears the store while this request is still in flight. Without this
-// the old tenant's rows are written back into the freshly cleared store and stay on
-// screen under the new tenant until a manual refresh.
-(0, operators_1.takeUntil)(actions$.pipe((0, operators_1.filter)(rootActions_1.clearAll.match))))));
-exports.fetchFailedJePostingsEpic = fetchFailedJePostingsEpic;