Document, backup, AI and update background jobs – behaviour
Steps, limits and tables of the text extraction, package unpacking, recognition, Drive sync, content translation, AI workflow, iPhone backup and update job types.
Job types
| Type | Behaviour | Tables |
|---|---|---|
doc_text (payload doc_id; queued by the document model's queueTextExtract()) | getDocRow(), column guard (hasTextColumns), dlbtdocstore->textOf($doc) (local, Drive, OneDrive; not only PDF), saved with saveExtractedText() (1 = extracted) | doc |
doc_zip_unpack (queued by an upload or the ZIP document's row action) | central, stoppable progress in the job table; a package on Drive is downloaded into a temporary folder under storage/ (max 300 MB per package, 1 GB total; when full, retry 10 minutes later); unpacking on upload only for a pure PDF package, otherwise the ZIP is one document; unpacking from the row action follows the folder structure; per entry from memory dlbtdocstore->addDocument(), in 40 s rounds with continuation rows; at the end the Drive package is deleted, a notification or e-mail goes to the initiator and doc_recognise is queued | doc, job, notification |
doc_recognise (per company) | with the admin document and invoice models, dlbtrecognise->run() in batches from the company's recognition queue (getRecogQueue); result setRecogResult() and recognition log (linked to invoice, not an invoice, failed); for group runs progress and a final notification or e-mail; remainder → continuation row | doc, invoice tables |
doc_drive_sync | folders of the client's active Drive storage rules (getActiveDriveObjStorages), 45 s per run, per folder max 10 pages × 200 items, max depth 15; document records for files not yet recorded; new PDFs into one doc_recognise job per company; progress and report to the initiator | doc |
content_translate (event-driven, with its own continuation rows) | the masterdata/translate model: AI setting (default Gemini gemini-2.5-flash), API key from the module settings (missing key is an error, no row written); per run max 12 rows or 45 s; language rows copied from the source language are translated with llmclient->chat() (HTML, links, numbers unchanged); a complete JSON answer is required, otherwise error; marked translated or unchanged; if rows remain, a new row in +60 s | content_translation, aiconfig, the website theme's translatable tables |
gpt_workflow (payload run_id) | processForCronqueue() of the workflow controller: dlbtgpt->tick(40, run_id); re-queued while the run is active. There is also a parallel worker slot entry point (slot 1–16, 10–600 s, slot lock 15 min, cron secret) started by the framework cron cron/gptworker (default 3, max 8 slots) after ensureQueued() | tables of the workflow library |
iphone_backup_stream, _extract, _index, _publish, _delete, _archive_purge (payload op, backup_id, from_index, optionally scope) | state machine of task/iphonebackup::processForCronqueue() by op: stream, zipindex, manifest, streampublish, extract, index, publish, messages, attachments, vcards, contacts, calendar, device, callhistory, geo, file data scopes, delete, purge. Each round works within a time limit and checkpoints; a new row carries the continuation; data scopes are serialised; the worker's chain guard resumes broken chains | backup, backup_file, backup_message, backup_message_attachment, backup_contact, backup_record, backup_scope_run, doc, doc_link, person, person_object, phonenumber, upload_session |
update_check (global, configured hourly interval with spread) | dlbtupdate->cronCheck(): version, central requests, starting an authorised automatic update; if a run started, update_apply is queued at once | update_config etc. |
update_apply (queued only by update_check or itself) | dlbtupdate->cronApply(35); continues every minute while working, every 15 minutes while waiting for approval or a time window; stops at done, failed, cancelled, rolled_back, verify_pending; in maintenance mode the worker runs only this | as above |