Limits of Discloud's retry idempotency for custom migration scripts

Goal: verify whether Discloud's deployment retry mechanism ensures exactly‑once execution for external database writes when users supply custom migration scripts.

Context: The platform automatically tags each write performed through its built‑in deployment hooks with a unique transaction ID, allowing retries to skip duplicates. Documentation confirms this behavior for Node.js and Python runtimes on the standard tier, but it does not explicitly state whether the same transaction‑ID tracking applies to user‑provided migration scripts that interact with external databases.

Uncertainty: If custom scripts bypass the hook‑level tracking, a retry could re‑run the script and cause duplicate writes, breaking the exactly‑once guarantee.

Questions: Does Discloud extend its transaction‑ID based deduplication to custom migration scripts? If not, what mechanisms should users implement to achieve idempotent external writes during retries?