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

ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ

បញ្ជូនសោ API ជា bearer token។ សោនេះត្រូវតែមានសិទ្ធិ sites.view។ សោដែលគ្មានសិទ្ធិនេះនឹងត្រូវបដិសេធដោយកូដ 403 មិនមែន 404 ទេ។

ចំនុចបញ្ចប់នេះមិនត្រូវការលេខសម្គាល់ស្ថាប័នទេ។ ពស័្ដកូនរបស់អ្នករួចហើយកំណត់អត្តសញ្ញាណស្ថាប័នដែលវាជាកម្មសិទ្ធិ ហើយការឆ្លើយតបគឺត្រូវបានកំណត់វិសាលភាពទៅតាមនោះ។

សាកល្បង

ជំនួសអ្វីមួយនៅក្នុងសញ្ញាពងក្រពើ < > ដោយប្រើតម្លៃផ្ទាល់ខ្លួនរបស់អ្នក ហើយជំនួសកន្លែងរក្សាទុកសោដោយប្រើសោចេញពីផ្ទាំងគ្រប់គ្រងរបស់អ្នក។

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