शापित ज्ञान

• Immich के विकास के दौरान सीखे गए शापित ज्ञान की सूची साझा की गई है
• विभिन्न software और infrastructure वातावरणों में पाए गए अप्रत्याशित समस्याओं का संकलन
• इसमें EXIF metadata, YAML whitespace handling, PostgreSQL जैसी टूल और भाषा-विशिष्ट समस्याओं का उल्लेख है
• कुछ मुद्दे सीधे security, platform compatibility और open source dependencies से जुड़े हुए हैं
• इसमें डेवलपर्स के लिए वास्तविक उदाहरण और कारण पर फोकस किया गया है

---

अवलोकन

Immich की विकास टीम ने परियोजना बनाते समय हुए उन शापित ज्ञान को सार्वजनिक किया है जिन्हें वे फिर कभी याद नहीं करना चाहते। यह सूची वास्तविक सेवा निर्माण और ऑपरेशन के दौरान अलग-अलग tools, languages और platforms में सीधे अनुभव किए गए अप्रत्याशित जाल और समस्याओं का वर्णन करती है।

शापित ज्ञान सूची

• 4 जून, 2025

  • Zitadel की Actions एक शापित फीचर है
  • Zitadel का दिया हुआ कस्टम स्क्रिप्टिंग फीचर JS engine पर आधारित है, लेकिन यह regex में नामित capture groups सपोर्ट नहीं करता, इसलिए इसकी सीमा तुरंत दिख जाती है

• 30 मई, 2025

  • Microsoft Entra में PKCE सपोर्ट मौजूद है, लेकिन इसे OpenID discovery दस्तावेज़ में स्पष्ट नहीं किया गया
  • इसलिए मौजूद फीचर को क्लाइंट पर detect नहीं किया जा सकता, जिससे समस्या आती है

• 5 मई, 2025

  • किसी image का विवरण देने वाला EXIF metadata का size वास्तविक image से अलग हो सकता है
  • इस अंतर की वजह से crop और resize ऑपरेशन में errors आ सकती हैं

• 1 अप्रैल, 2025

  • YAML में whitespace handling अपेक्षा के अनुसार काम न करके अलग तरह से behave कर सकता है
  • फ़ॉर्मैटिंग के प्रति संवेदनशील होने से कंटेंट गलत तरीके से interpret होने का खतरा रहता है

• 20 सितंबर, 2024

  • Windows के hidden files को "w" फ्लैग से नहीं खोला जा सकता
  • SMB के "hide dot files" विकल्प के साथ जोड़ने पर फाइल खोज और प्रोसेसिंग में अधिक भ्रम हो सकता है

• 7 अगस्त, 2024

  • Bash scripts में carriage return (CRLF) की समस्या आ सकती है
  • यदि Git checkout के दौरान tự LF को CRLF में बदल दे, तो स्क्रिप्ट रन करने पर error आ सकता है

• 7 अगस्त, 2024

  • Cloudflare Workers में fetch में https लिखने के बाद भी default में http लागू हो जाता है
  • इससे redirect loop जैसी नेटवर्क संबंधित समस्याएँ पैदा होती हैं

• 21 जुलाई, 2024

  • मोबाइल में GPS sharing तब silently GPS info हटा देता है जब app के पास location permission नहीं होती
  • इससे location-based services की accuracy और privacy दोनों पर असर पड़ता है

• 3 जुलाई, 2024

  • PostgreSQL का NOTIFY केवल transaction के अंदर काम करता है
  • socket.io के postgres-adapter के साथ उपयोग करने पर हर 5 सेकंड में WAL writes होती हैं, जिससे load बढ़ता है

• 3 जुलाई, 2024

  • प्रत्येक npm script रन पर npm registry को एक HTTP request भेजी जाती है
  • इसलिए health check अगर script से किया जाए तो वह inefficient हो जाता है

• 28 जून, 2024

  • JavaScript community के कुछ users ने "backward compatibility" के नाम पर लगभग 50 पैकेज dependencies ज़बरदस्ती जोड़ दीं
  • ये सभी पैकेज उसी उपयोगकर्ता द्वारा maintain किए गए थे

• 25 जून, 2024

  • bcrypt implementation केवल स्ट्रिंग के पहले 72 bytes उपयोग करता है
  • उसके बाद के characters ignore हो जाते हैं, इसलिए लंबा password अर्थहीन हो जाता है

• 31 जनवरी, 2024

  • JavaScript Date object में year और date 1 से शुरुआत करते हैं, जबकि month 0 से होता है
  • यह confusion पैदा करने वाली संरचना है

• 9 जनवरी, 2024

  • Node.js v20.8 से पहले, --experimental-vm-modules विकल्प वाले CommonJS प्रोजेक्ट में जब ES modules फिर से CommonJS module लाते हैं
    • तब segfault (segmentation fault) के कारण Node.js crash होने वाली समस्या आती है

• 28 दिसंबर, 2023

  • PostgreSQL में parameters की सीमा 65,535 है
  • बड़े data sets के bulk insert में यह performance bottleneck पैदा कर सकता है

• 26 जून, 2023

  • कुछ web APIs केवल Secure Contexts में उपलब्ध हैं
  • उदाहरण के लिए clipboard API केवल https या localhost environment में ही काम करती है

• 23 फरवरी, 2023

  • TypeORM का remove implementation सीधे इनपुट object को modify कर देता है
  • यह original object के id attribute तक हटाकर देता है

निष्कर्ष

ये शापित ज्ञान वास्तविक service development और operations में बार-बार आने वाले traps हैं। यदि डेवलपर्स हर tool, भाषा, और environment में छिपी हुई constraints और issues पहले ही पहचान लें, तो तेज़ समस्या समाधान और stable service निर्माण में मदद मिलती है।

[GN⁺]

Hacker News टिप्पणी

• इसे पहली बार देखने के बाद से ही बहुत पसंद आया था। उदाहरण कमिट (यहाँ) देखकर यह और भी अच्छा लगा। समस्या सुलझाने वाले code के साथ ‘शापित ज्ञान’ (cursed knowledge) को नोट करने का जो तरीका है, वो खास तौर पर अच्छा है। लगता है कि ऐसा feature हर प्रोजेक्ट में होना चाहिए। यह लॉग सिर्फ काथार्सिस नहीं बनता, बल्कि कई मुश्किल समस्याओं को positive learning experience में बदल देता है। अगर इसे बाहर शेयर करें तो वही issue झेल चुके लोग connect हो सकते हैं और आगे होने वाली दिक्कतों से बचने का tool भी बन सकता है।

  • मैं अक्सर ऐसी जानकारी सीधे commit message में लिख देता हूँ। कोई code लाइन देखकर अगर कहे, “इतना casually क्यों लिखा है? बस ___ कर देते न?”, तो तुरंत explanation मिल जाता है और काम आता है।

• ‘PostgreSQL में एक ही query में 65,000 placeholders bind नहीं किए जा सकते’ वाला हिस्सा देखकर मैं चौंक गया। शुरुआत से ही यह अच्छा idea नहीं लगा, इसलिए PostgreSQL को blame करना कठिन है। GitHub issue comments देखकर लगा कि उन्होंने ORM को refactor करके बड़े query को कई छोटे query में बाँटने जैसी sensible approach ली। निजी तौर पर मुझे हर query में करीब 3,000~5,000 rows ठीक लगते हैं। किसी ने सलाह दी कि पहले TEMP table में डेटा डालकर बाद में join करें—खासकर COPY … FROM वाला तरीका शायद performance में बेहतर है—लेकिन उस approach में code बदलाव बहुत बड़ा था, इसलिए अंततः वह strategy छोड़ दी गई। कुल मिलाकर यह अच्छे अनुभवों का उपयोगी संग्रह लगता है; warning case के रूप में ये बहुत काम का है।

• ‘यह कोशिश ही खुद एक cursed idea है’ वाली बात से मैं सहमत हूँ। पूरी सूची पढ़ने पर लगता है कि ‘शापित सूची’ कोई बंद गली या design trap नहीं, बल्कि वास्तविक developers द्वारा झेली गई और सीखी गई lessons हैं। निश्चित ही हर entry की quality अलग है और कुछ अभी भी जारी हैं, पर इन्हें engineering log में personal अनुभव समझा जाए तो ज़्यसी ज्यादा value मिलती है।

• फ़ाइल सिस्टम के सभी file नामों को बिना NUL character के xargs जैसी tool से एक साथ process करने की कोशिश जैसा महसूस होता है। अगर कोई नाम odd/broken हो या memory पर्याप्त न हो तो मुश्किल हो जाती है। इसलिए find -print0 और parallel -0/xargs -0 जैसी टूलिंग का use बेहतर है। और sed, grep जैसी commands को भी LC_ALL=C बिना चलाएँ तो multibyte character sequence errors आ सकते हैं, इसलिए सावधान रहें।

• मैंने खुद ORM से records का बड़ा upsert करते समय 65,000 bindings वाली error झेली है। खासकर जब table में SQL array type column हो, तब हर inserted item के हिसाब से bindings बदलते हैं। इसलिए दो बार रन करने पर भी rows/columns शायद समान दिखें, लेकिन required bind variables की संख्या बदलती रहती है और स्थिति unstable बन जाती है।

• दूसरा तरीका यह भी है कि values को array args (text[], int[] आदि) के रूप में पास करें। PostgreSQL इसे अच्छी तरह handle करता है। ANY() ऑपरेशन IN() से थोड़ा धीमा हो सकता है, लेकिन एक ही parameter में कई ID डालने की सुविधा देता है। शायद ORM ने उसे support नहीं किया होगा।

• ये part मुझे भी immediately दिखा। इतने ज्यादा parameters bind करना निश्चित रूप से cursed तरीका है। bulk processing में ज्यादातर COPY ही use करना चाहिए। सच में एक और cursed Postgres case जोड़ दूँ: prepared statement नाम silently NAMEDATALEN-1 भर ही काटे जाते हैं (NAMEDATALEN = 64)। यह 2001 से ऐसा था, और सच में पहले से मौजूद रहा। ORM को इसे निश्चित रूप से जानना चाहिए। कोई इंसान शायद ही 60 से अधिक character वाला prepare name लिखता है, लेकिन ORM अलग हैं।

• ‘50 अतिरिक्त packages install’ वाला आइटम सच में shocking था। लगता है उस package के author ने सिर्फ downloads बहुत बढ़ाए होंगे। global स्तर पर waste हो रहे bandwidth और disk space को देखें तो सच में बुरा लगता है। कहीं यह सिर्फ नाम कमाने की कोशिश तो नहीं?

  • इस ‘शापित ज्ञान’ में नाम लिए गए package maintainer TC39 member हैं। कई चर्चित JavaScript projects में यह व्यक्ति कई बार controversy में रहा है। कुछ specific polyfill issues में monetary motive की बातें भी थीं, लेकिन GitHub Sponsors या Tidelift से बड़ी earning नहीं दिखती, इसलिए शायद वे सच में compatibility को लेकर कड़े विश्वास से काम कर रहे हैं। 2025 तक आते-आते मेरी सोच थोड़ी बदल गई है। वे लगातार important maintenance कर रहे हैं, और community में बार-बार गलत राय रखने की भूमिका शायद शायद जरूरी भी होती है।
  • शायद यह reputation या किसी अलग शैली के कारण हो, लेकिन एक extreme interpretation यह भी है कि यह बड़े software supply chain attack की pre-setup हो सकती है।
  • वह author लगभग निश्चित रूप से ljharb ही लगता है।

• Windows का NTFS Alternate Data Streams (ADS) मौजूदा फाइल में असीमित फाइलें छिपाने की क्षमता देता है।
  macOS में data fork, xattr, Spotlight (md) indexing डिफ़ॉल्ट रूप से सभी हटाने योग्य volumes पर बहुत-सी hidden और temp files बना देता है। workaround: mdutil -X /Volumes/path/to/vol
  और opt-out telemetry बहुत ज्यादा जगहों पर है (go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter आदि), जहाँ privacy concerns भी हैं।

  • opt-out telemetry: go में default रूप से telemetry data सिर्फ local में store होता है। यूज़र जब चाहें तो केवल approved हिस्सा telemetry.go.dev पर upload कर सकते हैं। upload चालू करना go telemetry on से और पूरी तरह बंद करना go telemetry off से होता है (दस्तावेज़ देखें)।
  • सच में काम की telemetry सिर्फ opt-out telemetry ही है।

• ‘npm script चलने पर प्रत्येक बार npm registry को HTTP request भेजे जाते हैं’ वाली रिपोर्ट के बारे में सच जानना चाहूँगा। यदि ऐसा है तो package manager के हिसाब से यह अव्यावहारिक behavior है।

  • शायद यह npm update check करने का process हो। पुराने versions पर update notice भी दिख सकता है।
  • शायद यही कारण हो। कभी-कभी update banner भी दिख जाता है।

• लगता है कि एक item छूट गया। EXIF metadata में date/time handling वाला round तो काफी पुराने विवादों में से है।
  reference issue 1, reference issue 2, reference issue 3

  • date/time खुद भी cursed हो सकता है। ठीक से चल रहा हो फिर भी संबंधित फीचर में कभी भी issue आ सकता है। खासकर जब value में timezone या daylight saving शामिल हो।

• Hadoop और Kerberos वाला ‘Madness beyond the gates’ याद आता है (link)। इस पोस्ट ने कई बार मुझे ‘going crazy’ की स्थिति से बचाया है। लेखक Steve को धन्यवाद देना चाहता हूँ—कितना समय लगा होगा इतनी cursed knowledge निकालने में, सोचकर ही मुश्किल होता है।

• इस तरह शापित ज्ञान को एक जगह इकठ्ठा करने का concept बहुत अच्छा है। सच में, ऐसा अनुभव अक्सर project में गहराई तक उतरने पर ही मिलता है। आगे से हर project के लिए ऐसी सूची बनाने का plan है।

• यह आइटम cursed नहीं, बल्कि mobile OS permission management से जुड़ा security/privacy issue है।

• शानदार idea है! उत्सुकता है कि क्या और लोग अपनी cursed knowledge share करना चाहेंगे।
  मेरे अनुभव में MacOS filenames भी cursed हैं:

1. डिफ़ॉल्ट रूप से MacOS में file नाम case-sensitive नहीं होते (yani file.txt और FILE.txt बराबर हैं)।
2. MacOS में यदि नाम NFC में store करें तो कभी-कभी NFD में convert हो सकता है।

• मैंने 1995 में Windows 95 beta के समय CDDB पहली बार बनाई थी। CD albums के ट्रैक नाम जोड़कर .ini files में distribute किए, लेकिन .ini का 64KB size limit होने से project छोड़ना पड़ा।
• सही कहा। किसी भी system या data volume पर case-sensitive APFS या HFS+ volume बनाओ तो निश्चित issues आएंगे।
• पहला पॉइंट सिर्फ default सेटिंग है। HFS और APFS दोनों में case-sensitive विकल्प मौजूद है। NTFS भी यही behavior देता है। ये filesystems case-retentive हैं, इसलिए नीचे जैसा काम हो सकता है:

 $ echo yup > README.txt
 $ cat ReAdMe.TXT
 yup
 $ ls
 README.txt

असली समस्या यह है कि Steam case-sensitive file system पर install को ही refuse कर देता है, जबकि Linux version मौजूद होने के बावजूद।