@signiant/media-shuttle-sdk/dist/esm/src/internal/transfer/OrderedTransferUpdateManager.d.ts

The SDK for supporting file transfer to and from Media Shuttle

import PlatformService, { UpdateTransferBody, UpdateTransferOptions } from '../services/PlatformService';
export interface OrderedTransferUpdateManagerParams {
    platformService: PlatformService;
}
/**
 * We have seen instances where transfer requests reach their final destination out of order. Even assuming
 * the events are dispatched from the App in the correct order and are processed in the correct order then nature
 * of async/await behaviour means that when we are waiting for the results of 1 request (Request A) we could concurrently
 * be making another request (Request B). Under these circumstances Request A would typically begin first but
 * Request B "catches up" and surpasses resulting in out of order processing.
 *
 * This class exists to bring (more?) order to the chaos by allowing callers to queue up requests but only allow
 * processing of 1 element on the queue at a time. Since we only have 1 outbound request going to PAPI at a time
 * this should remove the possibility of race conditions between concurrent requests at the cost of slightly
 * delayed updates.
 *
 * We could write our own queue implementation but multiple pre-existing queue implementations exist with "safe"
 * libraries. "fastq" was chosen for its overwhelming popularity:
 * https://npmtrends.com/better-queue-vs-fastq-vs-js-queue-vs-queue
 *
 * Note, in testing both unit and manual (more clear before the debug logs were removed) we will see cases where a
 * second item is added to the queue before the first finishes processing but critically the second item does not
 * begin processing until the first is complete. This is the queue functioning as intended.
 *
 * Lastly, research suggests it is technically possible for a fastq to garbage collected before it is fully drained.
 * The chain of references here between the calling application and this queue are complicated. In principle if we
 * have a chain of awaits from where event processing begins it should be impossible to garbage collect before the
 * promises have concluded. The situation becomes less clear if callers are using then, etc. on the promise. Premature
 * garbage collection has not been seen in practice in testing to date.
 */
declare class OrderedTransferUpdateManager {
    private readonly _queue;
    constructor(params: OrderedTransferUpdateManagerParams);
    updateTransfer(options: UpdateTransferOptions): Promise<UpdateTransferBody>;
}
export default OrderedTransferUpdateManager;
//# sourceMappingURL=OrderedTransferUpdateManager.d.ts.map