<div class="key-takeaways"><ul><li>ข้อผิดพลาดระบุเพียงว่ามีพร็อพเพอร์ตี้ชื่อซ้ำกันอยู่แล้ว</li><li>Azure API Management บังคับให้ชื่อแสดงผล (name) ต้องไม่ซ้ำกันทั่วทั้งบริการ</li><li>การเพิ่มคำถามเรื่องตัวระบุตัวตนในดีไซน์รีวิวช่วยแก้ปัญหาที่ต้นเหตุ</li><li>การแก้ไขทำได้โดยเพิ่มการตรวจสอบความซ้ำซ้อนก่อนดำเนินการ PUT</li></ul></div><p>ข้อความแสดงข้อผิดพลาดสั้น ๆ ว่า "Property with the same name already exist" ปรากฏขึ้นพร้อมกับไปป์ไลน์ที่หยุดชะงักในเวลา 14.00 น. โดยไม่มีสแต็กเทรซหรือหมายเลขบรรทัดให้อ่าน ปฏิกิริยาแรกคือการพุ่งเป้าไปที่สคริปต์การเผยแพร่ แต่แท้จริงแล้วปัญหาเกิดจากตัว Azure API Management (APIM) เอง ที่ตัวแปรแบบ Named Values มีตัวระบุแยกกันสองส่วน ได้แก่ id ที่ได้จากชื่อโฟลเดอร์ และ name ซึ่งเป็นคุณสมบัติการแสดงผลที่ระบบบังคับให้ต้องไม่ซ้ำกันทั่วทั้งบริการ</p><p>ในกรณีนี้ มีการสร้างค่าผ่านพอร์ทัลด้วยมือไว้ล่วงหน้าแล้วหลายเดือนภายใต้ id อื่น แต่ดันไปตรงกับเงื่อนไขชื่อ name ที่ระบบกำลังจะเขียนทับ ส่งผลให้ APIM ปฏิเสธการเขียนข้อมูล ซึ่งดูเหมือนระบบพังแต่จริง ๆ เกิดจากการกระทำของคนสองคนที่ต่างก็ทำหน้าที่ของตนเองแต่ขาดการเชื่อมโยงข้อมูลระหว่างกัน ปัญหารูปแบบนี้เกิดขึ้นในสามระบบที่แตกต่างกันในปีนี้ และล้วนมีจุดเริ่มต้นจากช่องโหว่ในกระบวนการดีไซน์รีวิว</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/apim_naming_collision_msbc0bmz_inline_1_eb1eab5e2f.jpg" alt="software code debugging developer dashboard" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div></p><p>เมื่อเอกสารออกแบบแนะนำทรัพยากรใหม่ ผู้ตรวจสอบมักจะตั้งคำถามเดิม ๆ เช่น มันรองรับการขยายตัวหรือไม่ จุดล่มคืออะไร หรือใครเป็นผู้ดูแลในระบบโปรดักชัน ซึ่งคำถามเหล่านี้ไม่สามารถตรวจจับปัญหานี้ได้ คำถามที่ควรถูกหยิบยกมาถามคือ ทรัพยากรนี้มีตัวระบุมากกว่าหนึ่งตัวหรือไม่ และตัวใดกันแน่ที่ไม่ซ้ำกันในระดับขอบเขตใด วิศวกรส่วนใหญ่มักคิดว่าไอดีมีความไม่ซ้ำกันแล้วจบ แต่หลายแพลตฟอร์มแยกตัวระบุออกเป็นคีย์ที่ระบบสร้างขึ้นกับชื่อที่มนุษย์อ่านได้ และบังคับความไม่ซ้ำในจุดที่ไม่มีใครสังเกต</p><div class="ai-insight"><p>ช่องโหว่เรื่อง Compound Identity หรือตัวระบุที่มีหลายมิติ มักสร้างความปวดหัวให้กับทีมพัฒนาซอฟต์แวร์อยู่เสมอ เนื่องจากเครื่องมือหรือพอร์ทัลบริหารจัดการมักเปิดช่องให้ผู้ใช้งานสร้างข้อมูลผ่าน UI ได้โดยตรงนอกเหนือจากกระบวนการ CI/CD การทำความเข้าใจขอบเขตของตัวระบุ (Scope) จึงเป็นหัวใจสำคัญของการออกแบบคลาวด์เนทีฟทรัพยากรทุกประเภท เพื่อป้องกันความขัดแย้งที่คาดไม่ถึงในสภาพแวดล้อมจริง</p></div><p>การแก้ปัญหาที่ยั่งยืนไม่ใช่การปิดกั้นไม่ให้ใครสร้างข้อมูลผ่านพอร์ทัลด้วยมือ เพราะการทำเช่นนั้นเป็นเพียงการแก้ปัญหาปลายเหตุ แต่ควรเพิ่มข้อกำหนดลงในเทมเพลตเอกสารการออกแบบว่า สำหรับทรัพยากรที่มีตัวระบุซับซ้อน จะต้องระบุให้ชัดเจนว่าฟิลด์ใดไม่ซ้ำกัน และเกิดอะไรขึ้นหากเกิดการชนกัน ทีมงานได้แก้ไขด้วยการเพิ่มการตรวจสอบความซ้ำซ้อนในขั้นตอนการเผยแพร่โดยค้นหาตามชื่อก่อนทำคำสั่ง PUT ซึ่งช่วยเปลี่ยนเวลาในการแก้ปัญหา 45 นาทีให้กลายเป็นความผิดพลาดที่ตรวจพบได้ทันทีในไม่กี่วินาที</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/webruster/the-one-design-review-question-that-would-have-caught-our-apim-naming-collision-4eho" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>The error message simply stated that a property with the same name already existed.</li><li>Azure API Management enforces globally unique display names independent of resource IDs.</li><li>Adding an identifier scope question to design reviews prevents this root cause.</li><li>The practical fix involved adding an idempotency lookup check before the PUT request.</li></ul></div><p>The entire error message read "Property with the same name already exist," accompanied by a stuck deployment pipeline at 2 PM with no helpful stack trace or line number. The immediate instinct was to blame the apiops publisher config script, but the actual culprit was much more subtle: Azure API Management named values carry two separate identifiers where only one is strictly enforced for global uniqueness by the platform.</p><p>Specifically, there is the artifact folder-derived ID and the internal display name that APIM requires to be unique across the entire service. A named value had been manually created months earlier through the portal under a completely different ID, causing a name collision that the platform rejected. This same architectural blind spot has surfaced in three different systems this year, tracing back to identical gaps during the design review phase.</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/apim_naming_collision_msbc0bmz_inline_1_eb1eab5e2f.jpg" alt="software code debugging developer dashboard" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div></p><p>When design documents introduce new resources, reviewers naturally focus on scalability, failure modes, and production ownership—none of which catch identity collisions. The question that actually matters is whether a resource has multiple identifiers, which one is enforced as unique, and at what scope. Many engineers assume IDs are universally unique, but platforms frequently split identities into system keys and human-facing names, enforcing uniqueness on the field nobody is actively monitoring.</p><div class="ai-insight"><p>Compound identity issues frequently slip past architectural reviews because systems often allow manual creation through administration portals alongside automated pipelines. Clearly defining resource scopes and uniqueness constraints in architectural documentation bridges the gap between infrastructure-as-code deployments and manual administrative actions, preventing silent overwrites or unexpected conflict errors in production environments.</p><p>Instead of locking down the portal to block manual creation—which merely acts as governance theater—the team added an idempotency check to look up resources by name before executing any PUT requests, transforming a lengthy debugging session into an instant, self-explanatory pipeline failure.</p></div><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/webruster/the-one-design-review-question-that-would-have-caught-our-apim-naming-collision-4eho" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

large_article-1212.jpg

medium_article-1212.jpg

small_article-1212.jpg

thumbnail_article-1212.jpg

Inewgen

Inewgen

#Azure API Management

The One Design-Review Question That Would Have Caught Our APIM Naming Collision

Inewgen