fix(SUP-53128): do not restore entry if there is no file sync available

[inbalvasserman]

issue:
when do restore to entry, but there are no filesync that can be restored to ready state, the code change the file sync to status error, but still change the entry status to ready and then the entry cannot be played

solution:
add counter if file sync status was changed to ready, only then continue with the entry restoration

SUP-53128

[github-actions]

@github-copilot suggest

[shahbaa123]

🤖 AI PR Review

🚦 Verdict: 🟢 SAFE

Surgical Track B fix that correctly blocks entry/asset restoration when no file sync could actually be restored, matching the ticket's reported root cause; only minor nits found.

---

📌 Context Summary & Code Archaeology

Bug: restoreDeletedEntryAction could mark an entry (and its assets) as ready even when none of its file syncs could actually be restored (e.g. content purged long after deletion). restoreFileSyncs() would set every file sync to ERROR, but the caller ignored that outcome and proceeded to restore the entry anyway — producing an entry that looks restored in the UI but is not playable.

Fix: restoreFileSyncs() now returns whether at least one file sync was actually moved to READY. restoreDeletedEntryAction checks that return value and throws a new dedicated error (ENTRY_ASSETS_FILE_SYNC_CANNOT_RESTORE) before any entry/asset state is advanced, if the entry had file syncs but none of them were restorable.

Archaeology: This is the third iterative hardening of this exact restore path:

• An earlier fix added a path-suffix check (_purged) to the pre-flight validateEntryForRestoreDelete heuristic, to catch file syncs that were purged out-of-band while still flagged DELETED in the DB.
• A follow-up fix added an actual-file-existence check (kFile::checkFileExists) inside restoreFileSyncs itself, but only used it to set the file sync's own status — it wasn't yet propagated back to gate the entry-level restore decision.
• This PR closes that gap: instead of relying on a status/path heuristic ahead of time (as validateEntryForRestoreDelete does), it now gates the entry advance on the actual restoration outcome — the most authoritative signal available, and a strict improvement over the pre-flight heuristic.

Confirmed via repo-wide search that restoreFileSyncs has exactly one definition and one caller (both in this file), so there's no duplicated sibling logic carrying the same gap elsewhere, and no other caller is affected by the return-value change. Also confirmed the new error message contains the substring "cannot be restored", which admin_console/controllers/IndexController.php's existing error-categorization logic already matches on, so the admin console UI will correctly surface this as "Not Restorable" without any further caller-side changes.

---

📋 Actionable Feedback

1. MINOR — Style: missing space before =.
   File: plugins/admin_console/lib/errors/KalturaAdminConsoleErrors.php, line 9.
   The new constant omits the space that the sibling constant on the line above it uses.

   const ENTRY_ASSETS_FILE_SYNC_CANNOT_RESTORE = "ENTRY_ASSETS_FILE_SYNC_CANNOT_RESTORE;ENTRY_ID; Entry [@ENTRY_ID@] cannot be restored. No file sync available";

2. MINOR (out of scope, pre-existing) — Per-asset granularity gap.
   File: plugins/admin_console/services/EntryAdminService.php, asset-restore loop following the new guard.
   The new check only verifies that at least one file sync across the whole entry (thumbnail + all assets + convert logs + metadata) was restored. Individual assets are still unconditionally set to ASSET_STATUS_READY afterward regardless of whether their own specific file sync was restored. In a mixed scenario (some assets restorable, others not), an asset whose own file sync ended up in ERROR status would still be marked ready. This loop predates this PR and is unchanged by it — flagging for awareness only; recommend tracking in a separate ticket if a partially-restorable entry is reported.

[github-actions]

@github-copilot suggest

[github-actions]

@github-copilot suggest