Many attachments into one PDF, and nothing deleted until the merge is safe

The tool is started on demand and picks up invoices from the accounting system. A filter passes only an invoice in a usable state, its attachments are listed, and a second filter goes on only when there is more than one, since a single attachment needs no merge.

The attachment list is read up to fifteen files, the most the PDF service merges in one call, and the module's label says so, so the next person to edit it knows where the number came from. Each attachment is downloaded and an array aggregator gathers them into one bundle; a filter checks that at least one file came through before the merge is attempted.

Every external call (listing, downloading, merging, reading file ids, uploading and deleting) has a retry handler. The download and the merge also have a fallback: when the retries run out, a separate module makes a second attempt before the run resumes, so one stubborn file does not end the run.

Before the merged file is uploaded, a raw API call records the ids of the invoice's existing files. That list, taken before the merged PDF exists, is what the tool later deletes, so the new file can never be mistaken for an original and removed.

After a short wait the merged PDF is uploaded to the invoice. Only once that upload has succeeded does an iterator walk the recorded originals and delete each one that has a file id, each delete with its own retry. If the upload fails, the run stops there and every original is still in place, which the upload module's label states.