@zeniai/client-epic-state 5.2.52-betaRD1 → 5.2.53

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

@@ -1,40 +0,0 @@
-import { from, of } from 'rxjs';
-import { catchError, filter, switchMap, takeUntil } from 'rxjs/operators';
-import { updateJESchedules, updateJESchedulesDetails, } from '../../../../entity/jeSchedules/jeSchedulesReducer';
-import { createZeniAPIStatus, isSuccessResponse, } from '../../../../responsePayload';
-import { clearAll } from '../../../../rootActions';
-import { fetchFailedJePostings, fetchFailedJePostingsFailure, fetchFailedJePostingsSuccess, initializeJeScheduleLocalData, } from '../../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.
- */
-export const fetchFailedJePostingsEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(fetchFailedJePostings.match), switchMap(() => zeniAPI
-    .getJSON(`${zeniAPI.apiEndPoints.accountMicroServiceBaseUrl}/1.0/expenses_automation/failed_je_postings`)
-    .pipe(switchMap((response) => {
-    if (!isSuccessResponse(response) || response.data == null) {
-        return of(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 from([
-        updateJESchedules(failedJeSchedules),
-        updateJESchedulesDetails(failedJeSchedules, failedScheduledJournalEntries),
-        initializeJeScheduleLocalData(failedJeSchedules),
-        fetchFailedJePostingsSuccess(failedJeSchedules),
-    ]);
-}), catchError((error) => of(fetchFailedJePostingsFailure(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.
-takeUntil(actions$.pipe(filter(clearAll.match))))));