Levandor

FKITDEV-9005

6 min read

FKITDEV-9005 — Fundamenta “Scriptmódosítás hiba” (customer can’t see shared PDF on mobile)

Classification: YouTrack Task (State=In-progress); substance = production bug. Parent ASSFUNDA-73. Sibling/same-family CRFUNDA-30. Body empty — substance is in parent ASSFUNDA-73 (reporter “Lili”/milkovics.liliana) + the attached OSS logs.

✅ ROOT CAUSE (server-side, log-proven — 2026-07-30)

vuer_oss.tar.gz attached to ASSFUNDA-73 names the real failure. It is server-side Fundamenta flow logic, NOT the client PDF renderer.

Log-proven chain (prod videoertekesites.fundamenta.hu, 2026-07-10, room 3181 / customer 2666, flow funda-offer-tb-presentation = the “Értékesítés (TB)” script Lili named):

08:39:40 [ERROR] Error updating task 69817 FlowFrontendError: Presentation file task update restricted: required file was not set
    at FundaOfferTBPresentationFlowHandler.onBeforeUpdateTask
       (customization/flow/funda-offer-tb-presentation/funda-offer-tb-presentation.flow.handler.js:92)
    at FlowService.updateTask (server/flow/FlowService.js:2468)
    at Socket <videochat:flow:task:update> (server/socket/events/videochat.flow.js:142)   transKey:'task_file_error_required'
08:40:49 [ERROR] Failed to call presentation rpc server. Error: The presentation is not active for document (6322).

Mechanism:

  1. Operator client emits videochat:flow:task:update(flowId, taskId, data, skipped) for the presentation-open file task; data = the file payload.
  2. Fundamenta guard onBeforeUpdateTask (on origin/customization/fundamenta) throws when data is falsy for file tasks presentation-open / acceptance-open / statement-5-open / statement-6-open: 
    if (['presentation-open','acceptance-open','statement-5-open','statement-6-open'].includes(task.name) && !data)
  throw new FlowFrontendError('task_file_error_required', 'Presentation file task update restricted: required file was not set')
  3. Task update rejected → the presentation is never started/activated → customer GET /api/presentation-document/{documentId} → server/queue/rpc_server/Presentation.js RPC getDocument → _hasActivePresentation(roomId, documentId) false (no matching videochat:presentation:start activity, or a later stop) → throws “The presentation is not active for document (X)” → client PDFPresentation.open() catch → presentation_error = “Hiba történt a prezentáció indítása közben.”
  4. Operator sees the PDF (their view is ungated; doc is stored) — only the customer fetch is gated by _hasActivePresentation. Exactly Lili’s report.

Fix target — why does the presentation-open update arrive with falsy data? Decide from the operator-side update path + the FKITDEV-8889 diff:

  • (a) File binding lost after script reorder / editor-created file task → operator UI emits a dataless update. (A specific slice of the flow-republish idea — the file ref, not whole config.)
  • (b) Guard too broad — throws on any dataless update of those named tasks, but updates also fire for status/skip/reorder; a legit non-file update trips it.

Ties to CRFUNDA-30 / new feature: branch fix/FKITDEV-8889-fundamenta-extraCreatableProtoType enables File-task creation in the Flow Editor (File not in default creatableProtoType) = the CRFUNDA-30 feature (rel. 1.9.11.6). Same family ⇒ FKITDEV-9005 + CRFUNDA-30 share one server-side fix. Ferenc Jurkiewicz is already investigating CRFUNDA-30 — coordinate.

Routing: fix in vuer_oss customization/fundamenta (funda-offer-tb-presentation.flow.handler.js + operator-side presentation-open update / FKITDEV-8889), not vuer_css. Local vuer_oss checkout is on feature/FKITDEV-8947-unicredit… which lacks this code → branch from origin/customization/fundamenta.

Evidence caveats: presentation is not active = 549 hits May–Jul / 501 docs (partly benign: customer requests after stop); but the July-10 sequence is tightly correlated (task-update reject → same-room doc not-active 69s later) and is the most-recent occurrence of both families. required file was not set recurs Jan/Feb/Mar/Jul — long-standing guard, not new. Residual: ASSFUNDA-73 screenshot shows “Oldalak 1/1” (a getDocument success), mildly inconsistent with a fetch-level “not active” failure → possibly a second (client) facet or a different view; the mobile console András requested from Lili will disambiguate.

Symptom & sources

  • Customer, mobile, …-css.facekomtest.net (vuer_css): PDF viewer shows filename + “Oldalak 1/1” + zoom, blank canvas, red banner “Hiba történt a prezentáció indítása közben.” Screenshot FaceKom_hiba.jpg.
  • Operator sees/stores the PDF fine; doc openable in Ügymenetek. Rooms 9863/9864 (ASSFUNDA-73), 9857–9859 (CRFUNDA-30).
  • Dossiers: [[ASSFUNDA-73]] (parent + screenshot + vuer_oss.tar.gz), [[CRFUNDA-30]] (same error, new-file-task feature, room-export techlogs + Ferenc investigating).
  • Comment thread: András (user) asked Lili for a mobile-devtools console capture; Bence Varga asked for OSS log; Peter Szapora attached vuer_oss.tar.gz.

❌ Superseded: client-render (pdfjs toHex) hypothesis — investigated & REFUTED

Before the OSS logs, the lead was vuer_css client/utils/loadPdfJs.js (FKITDEV-8637 “PDFJS toHEX FIX”): pdfjs-dist v5 modern build calls Uint8Array.prototype.toHex() (in fingerprints), unpolyfilled → breaks on browsers lacking it; a legacy fallback is chosen when toHex absent.

  • Repro (faithful esbuild bundle of the exact loadPdfJs + pdfjs 5.4.624, Chrome with toHex deleted): legacy branch’s polyfill applies; fingerprints computes identically (no throw). Plus logical proof: loadPdfJs returns either native or polyfilled toHex, so it can never be missing at runtime.
  • ⇒ FKITDEV-8637 is correct; not the cause. Client render was the wrong tree — the OSS logs pointed to the server. (presentation_error string lives at vuer_css/client/ui/pages/videochat/videochat.trans.js:173, shown by both PdfView and PDFPresentation on any open/render failure — which is why it looked client-side.)

✅ FIX IMPLEMENTED (2026-07-30) — CORE, on devel, verified, NOT committed

Confirmed defect via subagent trace: the Flow Editor treats TaskProto.options as select-style strings only, so it (1) creates type:'file' tasks with no presentation options, and (2) overwrites existing file-task options with a string array on edit. Without options.featureControl.startPresentation / uiControl.openPresentationPanel the operator client (client/features/videochat/common/Flow/FlowItem.js) never auto-opens the presentation panel / never sends the file as data → guard throws → no videochat:presentation:start activity → _hasActivePresentation false → customer presentation_error.

Change — CORE server/flow/FlowService.js (branch fix/FKITDEV-9005-flow-editor-file-task-options off origin/devel, worktree vuer_oss-FKITDEV-9005):

  • New const FILE_TASK_PRESENTATION_OPTIONS = { uiControl:{openPresentationPanel:true}, featureControl:{startPresentation:true} }.
  • createFlowTask: type==='file' → options: FILE_TASK_PRESENTATION_OPTIONS; non-file unchanged (options.size still 0 → no options key). This is the whole fix — a single hunk.
  • Tests (test/tests/unit/flow-service.test.js): file-create sets structured options; non-file keeps string-array (regression). TDD: failed before, pass after.
  • Verified independently: unit suite 144/144 pass; eslint server/flow/FlowService.js clean (the one test-file no-new warning is pre-existing on devel + CI ignores test/*). Fixes CRFUNDA-30 directly (editor-created file tasks now work).

Validation (2026-07-30) — minimized after adversarial review. An earlier draft also guarded updateFlowTask (stop it clobbering a file task’s options). Removed as redundant + misplaced: the editor’s tasks.options come ONLY from the select-task-fields UI (client/ui/pages/taskProfile/TaskProfile.js:123 requires options only for type==='select'), so a file task edit always sends options:[] → the existing !tasks.options.length guard already returns → no clobber possible. And even if it were reachable, the guard sat after the real hazard (taskProto.options.find(...) on the now-object options). So the clobber path can’t occur; the single createFlowTask hunk is the minimal, complete fix. Const naming (SCREAMING_SNAKE) matches codebase module consts (ERROR_TYPES, IDENTIFICATION_TYPES, …); no-semi/no-comment style matched; shared const never mutated (safe).

NOT committed/pushed (gate armed). Open before this fully closes prod:

  1. Prod data patch — the code fix only helps new/edited tasks; Lili’s already-published flow version likely still has optionless file tasks → needs re-publish or a TaskProto.options patch for the 4 file tasks (presentation-open/acceptance-open/statement-5-open/statement-6-open) on the live version. Needs DB/prod access.
  2. ASSFUNDA-73 trigger — CRFUNDA-30 fully explained; ASSFUNDA-73 (reorder-only) not (reorder preserves options) → likely a file-task edit or a stale editor-made version. Confirm against the live flow version.
  3. Release path — core fix reaches Fundamenta prod only via a release (merge devel → fundamenta customization/release); an urgent hotfix would cherry-pick onto the fundamenta release branch.

Graph View