Timeout, pending, retry: ஒரு கோரிக்கை சேர்ந்ததா என்பதை எப்படித் தீர்மானிப்பது

ஒரு பொத்தானை அழுத்திய பிறகு திரையில் pending அல்லது processing என்று தோன்றினால், அடுத்து என்ன செய்வது என்பது அந்தக் காத்திருப்பு எந்த அமைப்பினுள் நடக்கிறது என்பதைப் பொறுத்தது. Spot ஆர்டர் காத்திருந்தால் அது Binance-ன் matching engine-க்குள் இருக்கிறது. வைப்பு காத்திருந்தால் அது சங்கிலியின் உறுதிப்படுத்தல்களுக்காகக் காத்திருக்கிறது. Simple Earn subscription அல்லது redemption காத்திருந்தால் அது அந்தத் தயாரிப்பின் நேர அட்டவணைக்குள் இருக்கிறது. வார்த்தை ஒன்றுதான்; காத்திருப்பை முடிவுக்குக் கொண்டுவரும் விதி மூன்றும் வேறு.

இந்த வேறுபாடு வெறும் சொல் விளையாட்டு அல்ல. ஆர்டர் அமைப்பில் அவசரமாக மீண்டும் அனுப்புவது இரட்டை நிலைப்பாட்டை உருவாக்கக்கூடும். வைப்பு அமைப்பில் மீண்டும் அனுப்ப ஒன்றுமே இல்லை — பணம் ஏற்கெனவே சங்கிலியில் நகர்ந்துவிட்டது, நீங்கள் செய்யக்கூடியது காத்திருப்பது மட்டுமே. Simple Earn-ல் அன்றைய சாளரம் மூடியிருந்தால் எத்தனை முறை அழுத்தினாலும் அது திறக்காது. ஒரே அறிகுறிக்கு மூன்று வெவ்வேறு சரியான பதில்கள் இருக்கின்றன.

எனவே இந்தப் பக்கம் முதலில் ஆர்டர் தரப்பை விரிவாக எடுத்துக்கொள்கிறது — ஏனெனில் அங்குதான் தவறான மறு அனுப்பல் உண்மையான பணச் செலவை உருவாக்குகிறது — பிறகு வைப்பு, திரும்பப்பெறல், Simple Earn ஆகியவற்றின் காத்திருப்பு விதிகளுக்கு நகர்கிறது. Spot திரையின் அடிப்படை சொற்கள் இன்னும் பரிச்சயமில்லை என்றால், Spot ஆர்டர் மற்றும் விலை risk விளக்கத்தை முதலில் படித்துவிட்டு இங்கு திரும்புவது எளிதாக இருக்கும்.

பலரும் timeout-ஐ ஒரு தோல்விச் செய்தியாகப் படிக்கிறார்கள். Spot பிழைக் குறியீட்டு ஆவணம் -1007 TIMEOUT-ஐ விளக்கும்போது பயன்படுத்தும் சொற்கள் அப்படி இல்லை: backend server-ன் பதிலுக்காகக் காத்திருந்து நேரம் முடிந்தது என்று சொன்ன பிறகு, ஆவணம் தொடர்ந்து Send status unknown; execution status unknown. என்று எழுதுகிறது. அதாவது கோரிக்கை சேர்ந்ததா என்பதும் தெரியாது, நிறைவேறியதா என்பதும் தெரியாது.

Unknown என்பது failed-ஐ விட மிகவும் விரிவான நிலை. அது தோல்வியையும் உள்ளடக்கும், முழுமையான வெற்றியையும் உள்ளடக்கும். திரையில் சிவப்புக் குறிப்பு தெரிந்ததால் ஆர்டர் engine-ஐ அடையவில்லை என்று முடிவுக்கு வருவது ஒரு ஊகம்; அந்த ஊகத்தின் மேல் இரண்டாவது ஆர்டரை அனுப்பினால், முதல் ஆர்டரும் ஏற்கப்பட்டிருந்தால் இரண்டு நிலைப்பாடுகள் ஒரே நேரத்தில் திறந்திருக்கும்.

இந்தப் பக்கத்தை எழுதும்போது ஒரு தேர்வு செய்தோம்: timeout சந்திக்கும் தருணத்தில் என்ன செய்யக் கூடாது என்பதைச் சொல்வதற்கு முன், அந்தச் செய்தி உண்மையில் என்ன சொல்கிறது என்பதை மட்டும் தனியாக நிற்க வைப்பது.

REST இடைமுகத்தின் பொதுத் தகவல் பக்கம் HTTP நிலைக் குறியீடுகளை இரு குடும்பங்களாகப் பிரிக்கிறது. 4XX குடும்பம் கோரிக்கையின் வடிவத்தில் பிழை இருப்பதைக் குறிக்கிறது; பிரச்சினை அனுப்புபவர் தரப்பில். 5XX குடும்பம் Binance பக்கத்தின் உள் பிழையைக் குறிக்கிறது, மேலும் ஆவணம் இதை ஒரு தோல்வி நடவடிக்கையாகக் கருதக் கூடாது என்று வலியுறுத்துகிறது — செயல் நிலை UNKNOWN, அது வெற்றியாகவும் இருந்திருக்கலாம்.

எனவே முதல் கேள்வி எப்போதும் ஒன்றுதான்: குறியீடு 4XX-ஆ, 5XX-ஆ.

4XX-க்குள்ளும் மூன்று வழக்குகள் தனியாகக் குறிக்கப்பட்டுள்ளன. 403 என்பது WAF விதி தூண்டப்பட்டது. 429 என்பது கோரிக்கை வீத வரம்பைத் தொட்டது. 418 என்பது 429 வந்த பிறகும் தொடர்ந்து அனுப்பியதால் IP தானாகத் தடை செய்யப்பட்டது. இந்த மூன்றாவது வழக்கு மறு அனுப்பல் குறித்த விவாதத்தில் நேரடியாக வந்து விழுகிறது: வேகமாக மீண்டும் அழுத்துவது நிலையை அறியத் தராது, ஆனால் அணுகலை இழக்கச் செய்யும்.

நடைமுறை வாசிப்பு இப்படி: 4XX கண்டால் கோரிக்கையைத் திருத்த வேண்டும், அதாவது ஏதோ ஒன்றை மாற்றாமல் அதே கோரிக்கையை அனுப்புவதில் பொருள் இல்லை. 5XX அல்லது timeout கண்டால் முதல் வேலை நிலையைச் சரிபார்ப்பது.

ஆர்டர் அனுப்பும்போது newClientOrderId என்ற புலத்தை நீங்களே நிரப்பலாம். ஆவணம் அதை இப்படி வரையறுக்கிறது: திறந்த ஆர்டர்களுக்கு இடையே தனித்துவமான ஒரு அடையாளம், நீங்கள் அனுப்பவில்லை என்றால் தானாக உருவாக்கப்படும். இதனுடன் ஒரு விதி சேர்ந்திருக்கிறது — அதே அடையாளத்துடன் வரும் ஆர்டர், முந்தையது filled ஆன பிறகுதான் ஏற்கப்படும்; இல்லையெனில் நிராகரிக்கப்படும்.

இது ஒரு தண்டனை போலத் தோன்றலாம், உண்மையில் இது ஒரு பாதுகாப்புத் தடுப்பு. Timeout-க்குப் பிறகு அதே அடையாளத்துடன் அதே ஆர்டரை மீண்டும் அனுப்பினால், முதல் ஆர்டர் ஏற்கெனவே திறந்திருந்தால் இரண்டாவது கோரிக்கை உள்ளே நுழையாது. நிராகரிப்புச் செய்தி அப்போது ஒரு பிழை அல்ல; அது “முதல் கோரிக்கை சேர்ந்துவிட்டது” என்ற தகவல்.

தானாக உருவாகும் அடையாளத்தை நம்பி விடுவது இங்குதான் விலை உயர்ந்ததாகிறது. ஒவ்வொரு மறு அனுப்பலும் புதிய அடையாளத்தைப் பெற்றால், அமைப்பைப் பொறுத்தவரை அவை முற்றிலும் தனித்தனி ஆர்டர்கள்; இரட்டிப்பைத் தடுக்க எதுவும் இல்லை. கையால் ஒரு அடையாளத்தை நிரப்பும் சிறிய கூடுதல் வேலைதான் இந்தத் தடுப்பை இயக்கும் திறவுகோல். நிபந்தனை ஆர்டர்களில் பல legs ஒன்றாக நகர்வதால் இந்த ஒழுக்கம் இன்னும் முக்கியமாகிறது.

PENDING_CANCEL-ஐ “ரத்துக் கோரிக்கை வரிசையில் காத்திருக்கிறது” என்று படிப்பது மிகச் சாதாரணமான தவறு. Spot ENUM அட்டவணை இந்த மதிப்புக்கு அருகில் தற்போது பயன்பாட்டில் இல்லை என்று வெளிப்படையாகக் குறித்திருக்கிறது. ரத்து நடந்ததா என்பதைத் தீர்மானிக்க CANCELED என்ற இறுதி மதிப்பையே பார்க்க வேண்டும்.

EXPIRED-ஐ அமைப்புக் கோளாறாகப் புரிந்துகொள்வது இரண்டாவது தவறு. ஆவணத்தின் வரையறை நேரடியானது: ஆர்டர் வகையின் விதிகளின்படி ரத்தானது அல்லது பரிமாற்றத்தால் ரத்து செய்யப்பட்டது. எடுத்துக்காட்டாக நிரப்பப்படாத LIMIT FOK, அல்லது ஒரு பகுதி மட்டும் நிரப்பப்பட்ட LIMIT IOC மற்றும் MARKET ஆர்டர்கள் இப்படி முடிவடையலாம். இது நீங்கள் தேர்ந்தெடுத்த ஆர்டர் வகையின் இயல்பான முடிவு.

மூன்றாவது EXPIRED_IN_MATCH. இது STP காரணமாகப் பரிமாற்றத்தால் காலாவதியாக்கப்பட்ட ஆர்டரைக் குறிக்கிறது.

ஆவணத்தில் NEW என்பது ஆர்டர் engine-ஆல் ஏற்கப்பட்டது என்று பொருள். PARTIALLY_FILLED என்றால் ஒரு பகுதி நிரப்பப்பட்டது; FILLED என்றால் முழுமையாக முடிந்தது. CANCELED என்பது பயனரால் ரத்து செய்யப்பட்டது. REJECTED என்பது engine ஏற்காமல் செயலாக்கவும் இல்லை என்பது. ஆர்டர் பட்டியல்களில் PENDING_NEW என்ற மதிப்பும் தோன்றும் — பட்டியலின் working order முழுமையாக நிரப்பப்படும் வரையிலான இடைப்பட்ட கட்டம் அது.

இதிலிருந்து ஒரு எளிய வேலைமுறை கிடைக்கிறது. NEW மற்றும் PARTIALLY_FILLED உயிரோடு இருக்கும் நிலைகள்; அவற்றுக்கு உங்கள் மூலதனம் ஏற்கெனவே ஒதுக்கப்பட்டிருக்கிறது. FILLED, CANCELED, REJECTED, EXPIRED ஆகியவை கதை முடிந்த நிலைகள். Timeout-க்குப் பிறகு நீங்கள் தேடும் ஒரே பதில் இதுதான் — இந்த ஆர்டர் உயிரோடு இருக்கிறதா, இல்லையா.

ஒரு நடைமுறைக் குறிப்பு: நிலைப் பெயர் மட்டும் போதாது, நிரப்பப்பட்ட அளவையும் சேர்த்துப் பார்க்க வேண்டும். PARTIALLY_FILLED ஆர்டரை ரத்து செய்தால் நிலை CANCELED ஆகும், ஆனால் ஏற்கெனவே நடந்த நிறைவேற்றம் மறையாது. தூண்டுதலும் நிறைவேற்றமும் தனித்தனி நிகழ்வுகள் என்ற அதே கருத்து இங்கும் பொருந்துகிறது.

வைப்பின் காத்திருப்பை முடிவுக்குக் கொண்டுவருவது சங்கிலியின் உறுதிப்படுத்தல்கள். அதிகாரப்பூர்வ உதவிப் பக்கம் சொல்வது எளிமையானது: அமைப்பு கோரும் குறைந்தபட்ச உறுதிப்படுத்தல்கள் நிறைவடைந்த பிறகே தொகை கணக்கில் சேரும். BTC வைப்பு திறக்கப்படுவதற்கு (unlocked) குறைந்தது 2 நெட்வொர்க் உறுதிப்படுத்தல்கள் தேவை என்று அதே பக்கம் குறிப்பிடுகிறது. தேவையான உறுதிப்படுத்தல் எண்ணிக்கை சங்கிலிக்குச் சங்கிலி மாறுபடும்; அன்றைய அதிகாரப்பூர்வ விளக்கமும் உங்கள் வைப்புப் பக்கத்தில் காட்டப்படும் தகவலுமே அளவுகோல்.

இங்கு உங்களிடம் இருக்கும் உண்மையான கருவி TxID. அதை block explorer-ல் வைத்துப் பார்த்தால் எத்தனை உறுதிப்படுத்தல்கள் ஆகியிருக்கின்றன என்பது தெரியும், மேலும் காத்திருப்பு எங்கே நிற்கிறது என்பதும் தெரியும். இந்தத் தகவல் பரிமாற்றத்தின் திரையில் இருந்து வருவதல்ல, சங்கிலியிலிருந்து வருகிறது; அதனால்தான் இது ஆதரவுக் கோரிக்கை அனுப்புவதற்கு முன் சேகரிக்க வேண்டிய முதல் விவரம்.

ஒரே தொகையை மீண்டும் அனுப்புவது இந்த அமைப்பில் ஒரு தீர்வே அல்ல. முதல் பரிமாற்றம் ஏற்கெனவே சங்கிலியில் இருக்கிறது; இரண்டாவது அனுப்புதல் இரண்டாவது வைப்பாகவே கருதப்படும். சங்கிலி அல்லது வலையமைப்பு தவறாகத் தேர்ந்தெடுக்கப்பட்ட வழக்குகளுக்கு வைப்பு மற்றும் திரும்பப்பெறல் பிழைகள் பக்கம் தனியாக உள்ளது.

திரும்பப்பெறலின் பக்கம் இரண்டு சொற்களை வேறுபடுத்துகிறது. Processing என்றால் உறுதிப்படுத்தல் நடைமுறை இன்னும் நடந்துகொண்டிருக்கிறது. Completed என்றால் தொகை வெற்றிகரமாக அனுப்பப்பட்டுவிட்டது. அதிகாரப்பூர்வ விளக்கத்தின்படி TxID பொதுவாக 1 முதல் 30 நிமிடங்களுக்குள் உருவாகும், அது பரிமாற்றம் ஒளிபரப்பப்பட்டுவிட்டது என்பதற்கான அறிகுறி.

TxID கிடைத்த பிறகு காத்திருப்பின் பொறுப்பு சங்கிலிக்கு மாறிவிடுகிறது. வலையமைப்பு நெரிசலான நேரங்களில் வழக்கத்துக்கு மாறான தாமதம் ஏற்படலாம் என்று அதே பக்கம் குறிப்பிடுகிறது. இந்தத் தருணத்தில் திரும்பப்பெறலை மீண்டும் சமர்ப்பிப்பது காத்திருப்பைக் குறைக்காது; அது இரண்டாவது வெளியேற்றத்தை உருவாக்கும் முயற்சி மட்டுமே.

பயனுள்ள வழக்கம் ஒன்று உண்டு: நிலை மாறும் ஒவ்வொரு தருணத்திலும் நேரத்தையும் நிலைப் பெயரையும் ஒரு குறிப்பில் எழுதி வைப்பது. கோரிக்கை அனுப்பிய நேரம், Processing தோன்றிய நேரம், TxID கிடைத்த நேரம் — இந்த மூன்று நேரங்கள் இருந்தால், பின்னர் ஆதரவைத் தொடர்பு கொள்ளும்போது உரையாடல் ஊகத்திலிருந்து தொடங்காது. குறிப்பில் ரகசியச் சொல், OTP, API secret எதையும் எழுத வேண்டாம்.

Simple Earn-ல் காத்திருப்பை முடிவு செய்வது பெரும்பாலும் ஒரு நேர அட்டவணை. அதிகாரப்பூர்வ விளக்கத்தின்படி subscription மற்றும் redemption செயல்பாடுகள் ஒவ்வொரு நாளும் தோராயமாக 00:10 முதல் 23:50 (UTC) வரையிலான சாளரத்தில் திறந்திருக்கும். அந்த இடைவெளிக்கு வெளியே கோரிக்கை ஏற்கப்படாதது எதிர்பார்க்கப்படும் நடத்தை.

சேர்ப்பு உறுதி செய்யப்பட்டவுடன் சொத்து spot பணப்பையிலிருந்து உடனே நகர்த்தப்படும் என்று அதே ஆவணம் சொல்கிறது. மீட்பு தரப்பில் நேரம் தயாரிப்பைப் பொறுத்து மாறுகிறது: Flexible-ன் விரைவு மீட்பு உடனடியாக spot பணப்பைக்குச் சேரும்; நிலையான மீட்பு அடுத்த நாள் கணக்கில் சேரும் என்று விவரிக்கப்படுகிறது, சரியான நேரம் நடப்பு இடைமுகத்தில் காட்டப்படுவதைப் பொறுத்தது; Locked தயாரிப்பின் முன்கூட்டிய மீட்புக்கு தோராயமாக 48 முதல் 72 மணி நேரம் ஆகலாம் என்று குறிப்பிடப்படுகிறது.

கூடுதலாக ஒரு முன்னெச்சரிக்கையும் ஆவணத்தில் உள்ளது: கடுமையான சந்தை நிலைமைகள், வலையமைப்புத் தாமதம் அல்லது ஒரே நேரத்தில் அதிக அளவு மீட்புக் கோரிக்கைகள் வரும்போது தாமதம் ஏற்படலாம். இந்த எண்கள் அனைத்தும் ஆவணம் விவரிக்கும் பொதுவான நேரங்கள்; உங்கள் கணக்கின் திரையில் காட்டப்படும் தேதியும் நிலையுமே இறுதி. தானியங்கிச் சேர்ப்பு தொடர்பான தனி விவரங்களுக்கு Simple Earn Auto-Subscribe வழிகாட்டி உள்ளது.

மேலே உள்ள சரிபார்ப்புகள் அனைத்தையும் செய்த பிறகும் நிலை தெளிவாகவில்லை என்றால், அது தொடர்ந்து முயற்சிப்பதற்கான அறிகுறி அல்ல. கணக்குத் தரவை உண்மையில் பார்க்கக்கூடியவர்கள் பரிமாற்றத்தின் ஆதரவுத் தரப்பு மட்டுமே. அந்தத் தருணத்தில் நீங்கள் கொண்டுசெல்ல வேண்டியவை: நேரம் (நேர மண்டலத்துடன்), சொத்து மற்றும் இணை, orderId அல்லது clientOrderId, TxID, திரையில் தோன்றிய பிழைக் குறியீடு.

அதே அளவு முக்கியமானது கொண்டுசெல்லக் கூடாதவை. கடவுச்சொல், 2FA குறியீடு, OTP, API secret, மீட்புச் சொற்றொடர் — இவற்றை எந்தச் சேனலிலும் யாருக்கும் அனுப்ப வேண்டியதில்லை. காத்திருப்பு நேரத்தில் தனிச் செய்தி அனுப்பி “ஆர்டரைச் சரிசெய்து தருகிறேன்” என்று சொல்பவர்கள் தோன்றுவது இந்த வகைத் தருணங்களில்தான்.

PADI ஒரு சுயாதீனக் கல்வித் தளம்; இது Binance-ஐ பிரதிநிதித்துவப்படுத்தாது, யாருடைய கணக்கையும் அணுகாது, நிதியைக் கையாளாது. இந்தப் பக்கத்தில் ஏதேனும் தவறு இருப்பதாகக் கருதினால் திருத்தங்கள் பக்கம் வழியாகத் தெரிவிக்கலாம்; பொறுப்பு எல்லைகள் பொறுப்புத்துறப்பு பக்கத்தில் உள்ளன.