POST /v1/sites/{siteId}/retry-provisioning

ການພິສູດຕົວຕົນ

ສົ່ງລະຫັດ API ເປັນ bearer token. ລະຫັດຕ້ອງມີສິດ sites.view; ລະຫັດທີ່ບໍ່ມີສິດດັ່ງກ່າວຈະຖືກປະຕິເສດດ້ວຍລະຫັດ 403, ບໍ່ແມ່ນ 404.

ຈຸດເຊື່ອມຕໍ່ນີ້ບໍ່ໄດ້ຮັບ ID ອົງກອນ. ລະຫັດຂອງທ່ານໄດ້ລະບຸອົງກອນທີ່ມັນຂຶ້ນກັບແລ້ວ, ແລະ ຄໍາຕອບແມ່ນຖືກຈໍາກັດຂອບເຂດໄວ້ສໍາລັບອົງກອນນັ້ນ.

ລອງໃຊ້ເບິ່ງ

ປ່ຽນແທນທຸກຢ່າງທີ່ຢູ່ໃນວົງເລັບມຸມດ້ວຍຄ່າຂອງທ່ານເອງ, ແລະ ປ່ຽນແທນຕົວແທນບ່ອນວ່າງຄີດ້ວຍຄີຈາກແຜງຄວບຄຸມຂອງທ່ານ.

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/retry-provisioning \
  -H "Authorization: Bearer zdk_live_…"

ເຂົ້າສູ່ລະບົບແລ້ວບໍ? ໂຄງສົນທະນາ API ໃນໜ້າັດສະຫຼອງຂອງທ່ານຈະຕື່ມຂໍ້ມູນລະຫັດອົງກອນຕົວຈິງ ແລະ ລະຫັດລັບສ່ວນຕົວຂອງທ່ານໂດຍອັດຕະໂນມັດ, ແລະ ປະຕິບັດການຮ້ອງຂໍຜ່ານ API ຕົວຈິງ ເພື່ອໃຫ້ທ່ານສາມາດເຫັນຜົນຕອບຮັບທີ່ແທ້ຈິງໄດ້. ເປີດຈຸດສິ້ນສຸດນີ້ໃນຄອນໂສລ API

ລາຍລະອຽດ

Re-runs provisioning for a site whose build failed or never started. The transition failed -> provisioning has always been legal and the status enum's own comment says "retry or delete" — this is the door. Idempotent, and pressing it twice is a success. A site that is already provisioning answers 202 with restarted: false rather than a 409: a customer pressing a button twice has not made an error. Three independent mechanisms make that safe — the workflow id is derived from the site id, the start policy is ALLOW_DUPLICATE_FAILED_ONLY so a completed provision can never be re-run, and the status transition locks and re-reads the row. ⛔ Nothing here calls Temporal (§2.9). The status change and a site.created event commit in one transaction and the existing consumer starts the workflow, so a Temporal outage cannot leave the row half-moved. A site that is active, deleting or deleted is a 422 — a retry re-runs the build, and those are past it. Requires sites.view and hosting.deploy.manage.

ພາຣາມິເຕີ

ຖືກໂຈະ

ຂໍ້ຜິດພາດທີ່ຈຸດເຊື່ອມຕໍ່ນີ້ສາມາດສົ່ງຄືນໄດ້

401 · 403 · 404 · 422 · 429