GitHub की हर object के पास दो ID होती हैं

• GitHub API का उपयोग करते समय PR comment link generation feature में ID mismatch की वजह से लिंक काम नहीं करने की समस्या सामने आई
• जांच में पता चला कि GitHub GraphQL के node ID और REST API के database ID नाम की दो अलग ID systems को साथ-साथ इस्तेमाल करता है
• node ID को base64 decode करने पर यह पुष्टि हुई कि उसके निचले 32-bit में database ID शामिल है, इसलिए एक सरल bitmask operation से इसे बदला जा सकता है
• अतिरिक्त विश्लेषण से यह भी सामने आया कि GitHub MessagePack-आधारित नए ID format और string-आधारित legacy format को मिलाकर इस्तेमाल कर रहा है
• यह संरचना GitHub के आंतरिक object identification system की द्वैधता को दिखाती है, और developers को API integration के समय सावधान रहने की जरूरत है

---

GitHub की दोहरी ID system की खोज

• Greptile के AI code review tool feature को विकसित करते समय GitHub PR comment links के काम न करने की समस्या आई
  • saved comment ID को URL में जोड़ा गया, लेकिन click करने पर GitHub page पर नहीं गया
• GitHub docs देखने पर पता चला कि GraphQL API का node ID और REST API का database ID अलग-अलग systems में मौजूद हैं
  • node ID उदाहरण: PRRC_kwDOL4aMSs6Tkzl8
  • database ID उदाहरण: 2475899260
• node ID, GitHub भर में objects को globally identify करने के लिए इस्तेमाल होने वाली base64-encoded string है, जबकि database ID integer URL identifier के रूप में उपयोग होती है

node ID और database ID के संबंध का विश्लेषण

• कई PR comments के node ID और database ID की तुलना करने पर पता चला कि दोनों values एक निश्चित अंतराल के साथ बढ़ती हैं
• node ID के base64 हिस्से को decode करने पर 96-bit integer बना, और इस value के निचले 32-bit database ID से मेल खाते थे
  • उदाहरण: PRRC_kwDOL4aMSs6Tkzl8 → निचले 32-bit = 2475899260
• एक सरल bitmask operation से database ID निकाली जा सकती है
  • decoded & ((1 << 32) - 1) जैसे operation से conversion किया जा सकता है

GitHub का legacy ID format

• पुराने repository (torvalds/linux) के node ID को decode करने पर अलग format की string दिखाई दी
  • उदाहरण: MDEwOlJlcG9zaXRvcnkyMzI1Mjk4 → 010:Repository2325298
• इस format की संरचना [object type number]:[object name][Database ID] है, यानी यह स्पष्ट string-based identifier है
• tree object के मामले में 04:Tree2325298:7201bfb9... जैसा रूप मिलता है, जिसमें repository ID और SHA value दोनों शामिल होते हैं
• GitHub legacy format और नए format दोनों का समानांतर उपयोग कर रहा है, और object type व creation time के अनुसार format बदलता है

नए node ID format की संरचना

• GitHub की GraphQL migration guide साफ कहती है कि node ID को opaque string की तरह मानना चाहिए, लेकिन इसकी आंतरिक संरचना मौजूद है
• base64 decode करने के बाद MessagePack से unpack करने पर array रूप में data दिखाई देता है
  • उदाहरण: [0, 47954445, 2475899260]
• array की संरचना
  • पहला element (0): version identifier होने का अनुमान
  • दूसरा element (47954445): repository का database ID
  • तीसरा element (2475899260): object का database ID
• object type के अनुसार array की length अलग होती है, और commit में SHA शामिल होता है, जबकि repository में सिर्फ दो elements होते हैं

व्यावहारिक उपयोग और निष्कर्ष

• नए node ID से database ID निकालने वाले Python code का उदाहरण

  import base64, msgpack
  def node_id_to_database_id(node_id):
      prefix, encoded = node_id.split('_')
      packed = base64.b64decode(encoded)
      array = msgpack.unpackb(packed)
      return array[-1]
  

• इस तरीके से PR comment का database ID सीधे निकालकर URL link की समस्या हल की जा सकती है
• GitHub फिलहाल MessagePack-आधारित नए ID system और string-based legacy system दोनों को एक साथ बनाए हुए है
• यह संरचना GitHub के आंतरिक transition process और compatibility बनाए रखने के प्रयास को दिखाती है, और API इस्तेमाल करने वाले developers को ID format के अंतर पर ध्यान देना चाहिए