[Mac] Initial sync does not run when a new binding is created #13

New issue

Closed

opened 2026-06-10 18:24:36 +02:00 by fpindado · 1 comment

fpindado commented

2026-06-10 18:24:36 +02:00

Owner

When a new binding is saved in the configuration panel on macOS, the initial sync (SP→MD or MD→SP depending on file state) does not execute.

The binding is eventually picked up via the 5-second polling fallback, but `performInitialSync` does not appear to run. Likely a timing issue with the `persistedDataUpdate` hook on the macOS build of SP. Needs developer console diagnostic to confirm root cause.

Steps to reproduce:

Open the configuration panel
Add a new binding pointing to an existing file
Wait — the initial sync does not occur

Expected behaviour: saving the binding should trigger the initial sync immediately.

When a new binding is saved in the configuration panel on macOS, the initial sync (SP→MD or MD→SP depending on file state) does not execute. The binding is eventually picked up via the 5-second polling fallback, but \`performInitialSync\` does not appear to run. Likely a timing issue with the \`persistedDataUpdate\` hook on the macOS build of SP. Needs developer console diagnostic to confirm root cause. **Steps to reproduce:** 1. Open the configuration panel 2. Add a new binding pointing to an existing file 3. Wait — the initial sync does not occur **Expected behaviour:** saving the binding should trigger the initial sync immediately.

fpindado added the

bug

label

2026-06-10 18:24:36 +02:00

fpindado self-assigned this

2026-06-10 18:24:36 +02:00

fpindado commented

2026-06-22 16:21:22 +02:00

Author

Owner

Fixed in v0.1.1 (pre-release).

Root cause (confirmed via console log, not just timing as originally suspected): the plugin registered the plugin-data hook as persistedDataUpdate, but SP 18.9.1D's valid hook name is persistedDataChanged. SP rejects the unknown name via typia validation, so the hook never fired — and the 5-second poll fallback wasn't compensating because it was wired up after a non-critical await refreshProjectsCache() in the startup IIFE.

Fix:

Renamed the hook persistedDataUpdate → persistedDataChanged (background, iframe, manifest).
Reordered the background entry point so the hook and the poll are registered before the project-cache refresh (now fire-and-forget).

Verified on macOS 18.9.1D: adding (3→4) and deleting (4→3) a binding both trigger the initial sync immediately, with no app restart and no typia errors in the console.

Released in pre-release v0.1.1.

Closing as fixed.

Fixed in v0.1.1 (pre-release). **Root cause** (confirmed via console log, not just timing as originally suspected): the plugin registered the plugin-data hook as `persistedDataUpdate`, but SP 18.9.1D's valid hook name is `persistedDataChanged`. SP rejects the unknown name via typia validation, so the hook never fired — and the 5-second poll fallback wasn't compensating because it was wired up after a non-critical `await refreshProjectsCache()` in the startup IIFE. **Fix:** - Renamed the hook `persistedDataUpdate` → `persistedDataChanged` (background, iframe, manifest). - Reordered the background entry point so the hook and the poll are registered before the project-cache refresh (now fire-and-forget). **Verified on macOS 18.9.1D:** adding (3→4) and deleting (4→3) a binding both trigger the initial sync immediately, with no app restart and no typia errors in the console. Released in pre-release v0.1.1. Closing as fixed.

fpindado closed this issue

2026-06-22 16:21:22 +02:00