पृष्ठभूमि प्रक्रिया पर ConnectionException के बजाय अस्वीकृति को फेंकने वाला गज़ल

9

मेरे पास कई कतार श्रमिकों पर चलने वाली नौकरियां हैं, जिसमें गुज़ल का उपयोग करके कुछ HTTP अनुरोध शामिल हैं। हालाँकि, GuzzleHttp\Exception\RequestExceptionजब इस कार्य को पृष्ठभूमि प्रक्रिया में चलाया जा रहा है , तो इस नौकरी के अंदर की कोशिश को रोक नहीं लगता है । रनिंग प्रक्रिया php artisan queue:workएक लारवेल कतार प्रणाली कार्यकर्ता है जो कतार की निगरानी करता है और नौकरियों को चुनता है।

इसके बजाय, जो अपवाद फेंका गया है GuzzleHttp\Promise\RejectionExceptionवह संदेश के साथ है:

वादे को अस्वीकार कर दिया गया था: cURL त्रुटि 28: ऑपरेशन 30001 मिलीसेकंड के बाद 0 बाइट्स के साथ प्राप्त हुआ (देखें https://curl.haxx.se/libcurl/c/libcurl-errin.html )

यह वास्तव में एक प्रच्छन्न है GuzzleHttp\Exception\ConnectException(देखें https://github.com/guzzle/promises/blob/master/src/RejectionException.php#L22 ), क्योंकि अगर मैं नियमित रूप से PHP प्रक्रिया में एक समान काम चलाता हूं जो कि एक पर जाकर ट्रिगर होता है URL, मुझे ConnectExceptionसंदेश के अनुसार इरादा मिलता है :

cURL त्रुटि 28: 100 मिलीसेकंड के बाद के ऑपरेशन में 0 बाइट्स में से 0 के साथ 100 मिलीसेकंड (देखें https://curl.haxx.se/libcurl/c/libcurl-errors.html )

सैंपल कोड जो इस टाइमआउट को ट्रिगर करेगा:

try {
    $c = new \GuzzleHttp\Client([
        'timeout' => 0.1
    ]);
    $response = (string) $c->get('https://example.com')->getBody();
} catch(GuzzleHttp\Exception\RequestException $e) {
    // This occasionally gets catched when a ConnectException (child) is thrown,
    // but it doesnt happen with RejectionException because it is not a child
    // of RequestException.
}

ऊपर कोड RejectionExceptionया तो या ConnectExceptionजब कार्यकर्ता प्रक्रिया में भाग जाता है, लेकिन हमेशा ConnectExceptionजब ब्राउज़र के माध्यम से मैन्युअल रूप से परीक्षण किया जाता है (जो मैं बता सकता हूं)।

इसलिए मूल रूप से जो मैं प्राप्त करता हूं, वह यह है कि यह RejectionExceptionसंदेश को लपेट ConnectExceptionरहा है, हालांकि मैं गुज़ल के अतुल्यकालिक सुविधाओं का उपयोग नहीं कर रहा हूं। मेरे अनुरोध बस श्रृंखला में किए गए हैं। केवल एक चीज जो अलग है वह यह है कि कई PHP प्रक्रियाएं गुज़ल एचटीटीपी कॉल कर सकती हैं या यह कि जॉब्स खुद ही टाइम आउट कर रही हैं (जिसके परिणामस्वरूप एक अलग अपवाद लारवेल का होना चाहिए Illuminate\Queue\MaxAttemptsExceededException), लेकिन मैं नहीं देखती कि यह कैसे कोड को अलग तरह से व्यवहार करने का कारण बनता है।

मैं Guzzle संकुल के अंदर किसी भी कोड को नहीं पा सकता php_sapi_name()/ रही हूँ PHP_SAPI(जो कि उपयोग किए गए इंटरफ़ेस को निर्धारित करता है) एक ब्राउज़र ट्रिगर के विपरीत, CLI से चलने पर विभिन्न सामानों को निष्पादित करने के लिए।

tl; डॉ

गुज़ले ने मुझे RejectionExceptionअपने कार्यकर्ता प्रक्रियाओं पर क्यों फेंका , लेकिन ConnectExceptionनियमित PHP लिपियों पर ब्राउज़र के माध्यम से ट्रिगर किया गया?

संपादित करें 1

अफसोस की बात है कि मैं एक न्यूनतम प्रजनन योग्य उदाहरण नहीं बना सकता। मुझे अपने संतरी अंक ट्रैकर में कई त्रुटि संदेश दिखाई देते हैं, ऊपर दिखाए गए सटीक अपवाद के साथ। स्रोत के रूप में कहा गया है Starting Artisan command: horizon:work(जो लारवेल क्षितिज है, यह लारवेल कतारों की देखरेख करता है)। मैंने फिर से जाँच की है कि क्या PHP संस्करणों के बीच कोई विसंगति है, लेकिन वेबसाइट और कार्यकर्ता दोनों प्रक्रियाएं एक ही PHP को चलाती हैं 7.3.14जो ठीक है:

PHP 7.3.14-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Jan 23 2020 13:59:16) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.14, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.14-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
  • CURL संस्करण है cURL 7.58.0।
  • गुज़ले संस्करण है guzzlehttp/guzzle 6.5.2
  • लारवेल संस्करण है laravel/framework 6.12.0

2 संपादित करें (स्टैक ट्रेस)

    GuzzleHttp\Promise\RejectionException: The promise was rejected with reason: cURL error 28: Operation timed out after 30000 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
    #44 /vendor/guzzlehttp/promises/src/functions.php(112): GuzzleHttp\Promise\exception_for
    #43 /vendor/guzzlehttp/promises/src/Promise.php(75): GuzzleHttp\Promise\Promise::wait
    #42 /vendor/guzzlehttp/guzzle/src/Client.php(183): GuzzleHttp\Client::request
    #41 /app/Bumpers/Client.php(333): App\Bumpers\Client::callRequest
    #40 /app/Bumpers/Client.php(291): App\Bumpers\Client::callFunction
    #39 /app/Bumpers/Client.php(232): App\Bumpers\Client::bumpThread
    #38 /app/Models/Bumper.php(206): App\Models\Bumper::post
    #37 /app/Jobs/PostBumper.php(59): App\Jobs\PostBumper::handle
    #36 [internal](0): call_user_func_array
    #35 /vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(32): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}
    #34 /vendor/laravel/framework/src/Illuminate/Container/Util.php(36): Illuminate\Container\Util::unwrapIfClosure
    #33 /vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(90): Illuminate\Container\BoundMethod::callBoundMethod
    #32 /vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(34): Illuminate\Container\BoundMethod::call
    #31 /vendor/laravel/framework/src/Illuminate/Container/Container.php(590): Illuminate\Container\Container::call
    #30 /vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(94): Illuminate\Bus\Dispatcher::Illuminate\Bus\{closure}
    #29 /vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(130): Illuminate\Pipeline\Pipeline::Illuminate\Pipeline\{closure}
    #28 /vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(105): Illuminate\Pipeline\Pipeline::then
    #27 /vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(98): Illuminate\Bus\Dispatcher::dispatchNow
    #26 /vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(83): Illuminate\Queue\CallQueuedHandler::Illuminate\Queue\{closure}
    #25 /vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(130): Illuminate\Pipeline\Pipeline::Illuminate\Pipeline\{closure}
    #24 /vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(105): Illuminate\Pipeline\Pipeline::then
    #23 /vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(85): Illuminate\Queue\CallQueuedHandler::dispatchThroughMiddleware
    #22 /vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(59): Illuminate\Queue\CallQueuedHandler::call
    #21 /vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(88): Illuminate\Queue\Jobs\Job::fire
    #20 /vendor/laravel/framework/src/Illuminate/Queue/Worker.php(354): Illuminate\Queue\Worker::process
    #19 /vendor/laravel/framework/src/Illuminate/Queue/Worker.php(300): Illuminate\Queue\Worker::runJob
    #18 /vendor/laravel/framework/src/Illuminate/Queue/Worker.php(134): Illuminate\Queue\Worker::daemon
    #17 /vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(112): Illuminate\Queue\Console\WorkCommand::runWorker
    #16 /vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(96): Illuminate\Queue\Console\WorkCommand::handle
    #15 /vendor/laravel/horizon/src/Console/WorkCommand.php(46): Laravel\Horizon\Console\WorkCommand::handle
    #14 [internal](0): call_user_func_array
    #13 /vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(32): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}
    #12 /vendor/laravel/framework/src/Illuminate/Container/Util.php(36): Illuminate\Container\Util::unwrapIfClosure
    #11 /vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(90): Illuminate\Container\BoundMethod::callBoundMethod
    #10 /vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(34): Illuminate\Container\BoundMethod::call
    #9 /vendor/laravel/framework/src/Illuminate/Container/Container.php(590): Illuminate\Container\Container::call
    #8 /vendor/laravel/framework/src/Illuminate/Console/Command.php(201): Illuminate\Console\Command::execute
    #7 /vendor/symfony/console/Command/Command.php(255): Symfony\Component\Console\Command\Command::run
    #6 /vendor/laravel/framework/src/Illuminate/Console/Command.php(188): Illuminate\Console\Command::run
    #5 /vendor/symfony/console/Application.php(1012): Symfony\Component\Console\Application::doRunCommand
    #4 /vendor/symfony/console/Application.php(272): Symfony\Component\Console\Application::doRun
    #3 /vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application::run
    #2 /vendor/laravel/framework/src/Illuminate/Console/Application.php(93): Illuminate\Console\Application::run
    #1 /vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(131): Illuminate\Foundation\Console\Kernel::handle
    #0 /artisan(37): null

Client::callRequest()समारोह बस एक guzzle ग्राहक जिस पर मैं फोन शामिल हैं $client->request($request['method'], $request['url'], $request['options']);(ताकि im का उपयोग नहीं requestAsync())। मुझे लगता है कि इसके समानांतर चलने वाली नौकरियों के साथ कुछ करना है जो इस मुद्दे का कारण बनता है।

3 संपादित करें (समाधान पाया गया)

निम्नलिखित टेस्टकेस पर विचार करें जो एक HTTP अनुरोध करता है (जो एक नियमित 200 प्रतिक्रिया लौटना चाहिए):

        try {
            $c = new \GuzzleHttp\Client([
                'base_uri' => 'https://example.com'
            ]);
            $handler = $c->getConfig('handler');
            $handler->push(\GuzzleHttp\Middleware::mapResponse(function(ResponseInterface $response) {
                // Create a fake connection exception:
                $e = new \GuzzleHttp\Exception\ConnectException('abc', new \GuzzleHttp\Psr7\Request('GET', 'https://example.com/2'));

                // These 2 lines both cascade as `ConnectException`:
                throw $e;
                return \GuzzleHttp\Promise\rejection_for($e);

                // This line cascades as a `RejectionException`:                
                return \GuzzleHttp\Promise\rejection_for($e->getMessage());
            }));
            $c->get('');
        } catch(\Exception $e) {
            var_dump($e);
        }

अब मैंने rejection_for($e->getMessage())जो किया वह मूल रूप से कॉल था जो RejectionExceptionसंदेश स्ट्रिंग के आधार पर अपना स्वयं का बनाता है । कॉलिंग rejection_for($e)यहाँ सही समाधान था। जवाब देने के लिए केवल एक चीज बची है, यदि यह rejection_forफ़ंक्शन एक सरल के समान है throw $e।

php  laravel  queue  background-process  guzzle 
— ज्योति
स्रोत
आप किस गज़ल संस्करण का उपयोग करते हैं?
— व्लादिमीर
1
लारवेल के लिए आप किस कतार चालक का उपयोग करते हैं? उदाहरण / प्रति उदाहरण पर कितने कार्यकर्ता समानांतर चल रहे हैं? क्या आपके पास कस्टम गज़ल मिडलवेयर की जगह है (संकेत:) HandlerStack?
— क्रिस्टोफ क्लूज
आप संतरी से एक स्टैक ट्रेस प्रदान कर सकते हैं?
— व्लादिमीर
@Vladimir ive ने स्टैक ट्रेस को जोड़ा। मुझे नहीं लगता कि यह आपकी बहुत सहायता करेगा। जिस तरह से गुज़्ज़ल (और सामान्य रूप से PHP) में वादों को लागू किया जाता है वह पढ़ना मुश्किल है।
— फ्लेम
1
@ क्या आप उस मिडलवेयर को साझा कर सकते हैं जो सब-गज़ल अनुरोध करता है? मुझे लगता है कि मुद्दा वहाँ होगा। इस बीच मैं अपनी थीसिस के साथ एक प्रतिलिपि प्रस्तुत करने योग्य उत्तर जोड़ूंगा।
— क्रिस्टोफ क्लूज

जवाबों:

3

हैलो मैं जानना चाहूंगा कि क्या आप 4xx त्रुटि कर रहे हैं या त्रुटि 5xx

लेकिन फिर भी मैं समाधान के लिए कुछ विकल्प रखूँगा जो आपकी समस्या से मिलता जुलता है

वैकल्पिक 1

मैं इसे टक्कर देना चाहता हूं, मेरे पास यह मुद्दा था कि एक नए उत्पादन सर्वर के विकास और परीक्षण वातावरण की तुलना में अप्रत्याशित 400 प्रतिक्रियाएं लौट रही हैं जो अपेक्षित रूप से काम कर रहे हैं; बस ap को स्थापित करने के लिए php7.0-कर्ल को ठीक करें।

यह एक नया उबंटू था 16.04 LTS pp के माध्यम से स्थापित php के साथ स्थापित: ondrej / php, डिबगिंग के दौरान मैंने देखा कि हेडर अलग थे। दोनों chucked डेटा के साथ एक बहु-भाग फॉर्म भेज रहे थे, हालांकि php7.0-कर्ल के बिना यह एक कनेक्शन भेज रहा था: उम्मीद के बजाय करीब हेडर: 100-जारी; दोनों अनुरोध जिनमें से ट्रांसफर-एन्कोडिंग था: चंकड।

  वैकल्पिक 2

शायद आपको यह कोशिश करनी चाहिए

try {
$client = new Client();
$guzzleResult = $client->put($url, [
    'body' => $postString
]);
} catch (\GuzzleHttp\Exception\RequestException $e) {
$guzzleResult = $e->getResponse();
}

var_export($guzzleResult->getStatusCode());
var_export($guzzleResult->getBody());

यदि प्रतिक्रिया कोड 200 नहीं है, तो गुज़ले को कैचिंग की आवश्यकता है

वैकल्पिक 3

मेरे मामले में ऐसा इसलिए था क्योंकि मैंने अनुरोध के $ विकल्प ['json'] में एक खाली सरणी पास कर दी थी, मैं कंटेंट-टाइप: एप्लिकेशन / json रिक्वेस्ट हेडर को पास करते हुए भी पोस्टमैन या CURL का उपयोग कर सर्वर पर 500 को पुन: पेश नहीं कर सका।

वैसे भी, अनुरोध के विकल्प सरणी से json कुंजी को हटाने से समस्या हल हो गई।

मैंने 30 मिनट बिताए, यह पता लगाने की कोशिश कर रहा है कि क्या गलत है क्योंकि यह व्यवहार बहुत असंगत है। अन्य सभी अनुरोधों के लिए, मैं $ विकल्प पास कर रहा हूं ['json'] = [] किसी भी समस्या का कारण नहीं था। यह एक सर्वर समस्या हो सकती है, मैं सर्वर को नियंत्रित नहीं करता हूं।

प्राप्त विवरण पर प्रतिक्रिया भेजें

— PauloBoaventura
स्रोत
अच्छा ... एक तेज़ और अधिक सटीक उत्तर देने के लिए। मैंने GitHub पर प्रोजेक्ट पेज पर प्रश्न पोस्ट करने की पहल की। मुझे आशा है कि आपको github.com/guzzle/guzzle/issues/2599
— PauloBoaventura
1
एक ConnectExceptionसंबद्ध प्रतिक्रिया नहीं है, इसलिए जहां तक ​​मुझे पता है 400 या 500 त्रुटि नहीं है। ऐसा लगता है कि आप वास्तव में पकड़ने की जानी चाहिए BadResponseException(या ClientException(4xx) / ServerException(5xx) जो इसके बारे में दोनों बच्चे हैं)
— लौ
— PauloBoaventura
2

Guzzle तुल्यकालिक और अतुल्यकालिक दोनों अनुरोधों के लिए वादों का उपयोग करता है। एकमात्र अंतर यह है कि जब आप सिंक्रोनस अनुरोध (आपके मामले) का उपयोग करते हैं - यह एक wait() विधि को कॉल करके तुरंत पूरा होता है । इस भाग पर ध्यान दें:

waitअस्वीकार किए गए वादे पर बुलाना अपवाद को फेंक देगा। यदि अस्वीकृति कारण कारण का एक उदाहरण \Exceptionहै। अन्यथा, एक GuzzleHttp\Promise\RejectionException फेंक दिया जाता है और इसका कारण getReason अपवाद की विधि को कॉल करके प्राप्त किया जा सकता है।

तो, यह फेंकता है RequestExceptionजो एक उदाहरण है \Exceptionऔर यह हमेशा 4xx और 5xx HTTP त्रुटियों पर होता है, जब तक कि अपवादों को फेंकना विकल्पों के माध्यम से अक्षम नहीं किया जाता है। जैसा कि आप देखते हैं, यह भी फेंक सकता है RejectionExceptionयदि कारण उदाहरण का \Exceptionउदाहरण नहीं है यदि कारण एक स्ट्रिंग है जो लगता है कि आपके मामले में होता है। अजीब बात यह है कि आप कनेक्शन टाइमआउट त्रुटि पर गुज़ले फेंकने के RejectExceptionबजाय प्राप्त करते हैं । वैसे भी, आपको एक कारण मिल सकता है यदि आप संतरी में अपने स्टैक ट्रेस से गुजरते हैं और यह पाते हैं कि विधि को प्रॉमिस पर कहाँ कहा जाता है।RequestExceptionConnectExceptionRejectExceptionreject()

— व्लादिमीर
स्रोत
1

मेरे जवाब के लिए एक स्टार्टर के रूप में टिप्पणी अनुभाग के अंदर लेखक के साथ चर्चा:

सवाल:

क्या आपके पास कस्टम गज़ल मिडलवेयर की जगह है (संकेत: हैंडलरस्टैक)?

लेखक का उत्तर:

हाँ विभिन्न। लेकिन मिडलवेयर मूल रूप से एक अनुरोध / प्रतिक्रिया संशोधक है, यहां तक ​​कि मेरे द्वारा किए जाने वाले गज़ल अनुरोध भी सिंक्रोनाइज़ किए जाते हैं।

इसके अनुसार यहाँ मेरी थीसिस है:

आपके पास अपने मिडलवेयर के अंदर एक टाइमआउट है, जिसे गज़ल कहते हैं। तो चलो एक प्रतिलिपि प्रस्तुत करने योग्य मामले को लागू करने की कोशिश करते हैं।

यहां हमारे पास एक कस्टम मिडलवेयर है, जो गज़ल कहता है और सब-कॉल के अपवाद संदेश के साथ एक अस्वीकृति विफलता देता है। यह बहुत मुश्किल है, क्योंकि आंतरिक त्रुटि-हैंडलिंग के कारण यह स्टैक-ट्रेस के अंदर अदृश्य हो जाता है।

function custom_middleware(string $baseUri = 'http://127.0.0.1:8099', float $timeout = 0.2)
{
    return function (callable $handler) use ($baseUri, $timeout) {
        return function ($request, array $options) use ($handler, $baseUri, $timeout) {
            try {
                $client = new GuzzleHttp\Client(['base_uri' => $baseUri, 'timeout' => $timeout,]);
                $client->get('/a');
            } catch (Exception $exception) {
                return \GuzzleHttp\Promise\rejection_for($exception->getMessage());
            }
            return $handler($request, $options);
        };
    };
}

यह एक परीक्षण उदाहरण है कि आप इसका उपयोग कैसे कर सकते हैं:

$baseUri = 'http://127.0.0.1:8099'; // php -S 127.0.0.1:8099 test.php << includes a simple sleep(10); statement
$timeout = 0.2;

$handler = \GuzzleHttp\HandlerStack::create();
$handler->push(custom_middleware($baseUri, $timeout));

$client = new Client([
    'handler' => $handler,
    'base_uri' => $baseUri,
]);

try {
    $response = $client->get('/b');
} catch (Exception $exception) {
    var_dump(get_class($exception), $exception->getMessage());
}

जैसे ही मैं इस के खिलाफ एक परीक्षण कर रहा हूँ मैं प्राप्त कर रहा हूँ 

$ php test2.php 
string(37) "GuzzleHttp\Promise\RejectionException"
string(174) "The promise was rejected with reason: cURL error 28: Operation timed out after 202 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)"

तो ऐसा लगता है कि आपका मुख्य गुत्थी कॉल विफल हो गया लेकिन वास्तव में यह उप-कॉल है जो विफल रहा।

मुझे बताएं कि क्या इससे आपको अपने विशिष्ट मुद्दे की पहचान करने में मदद मिलती है। अगर आप इसे थोड़ा और आगे बढ़ाने के लिए अपने बिचौलियों को साझा कर सकते हैं तो मुझे भी बहुत सराहना मिलेगी।

— क्रिस्टोफ़ क्लुगे
स्रोत
ऐसा लगता है कि आप सही हैं! मैं उस मिडलवेयर में कहीं के rejection_for($e->getMessage())बजाय कॉल कर रहा था rejection_for($e)। मैं डिफ़ॉल्ट मिडलवेयर के लिए मूल स्रोत को देख रहा था (जैसे यहाँ: github.com/guzzle/guzzle/blob/master/src/Middleware.php#L106 ), लेकिन यह बताने में असमर्थ था कि rejection_for($e)इसके बजाय क्यों थे throw $e। यह मेरे टेस्टकेस के अनुसार उसी तरह कैस्केड करता है। सरलीकृत टेस्टकेस के लिए मूल पोस्ट देखें।
— ज्वाला
1
@ मुझे खुशी है कि मैं आपकी मदद कर सकता हूं :) आपके दूसरे प्रश्न के अनुसार: यदि उनके बीच कोई अंतर है। खैर यह वास्तव में उपयोग के मामले तक है। आपके विशिष्ट परिदृश्य में इससे कोई फ़र्क नहीं पड़ेगा (उपयोग किए गए अपवाद वर्ग को छोड़कर) क्योंकि आपके पास केवल एक कॉल है। यदि आप एक ही बार में कई और async कॉल पर स्विच करने पर विचार करते हैं, तो आपको कोड-रुकावटों से बचने के वादे का उपयोग करने पर विचार करना चाहिए, जबकि अन्य अनुरोध अभी भी चल रहे हैं। यदि आपको मेरे उत्तर को स्वीकार करने के लिए अधिक जानकारी की आवश्यकता है, तो कृपया मुझे बताएं :)
— क्रिस्टोफ़ क्लूज
0

नमस्कार मुझे समझ नहीं आया कि आपने अपनी समस्या को हल किया या नहीं।

वैसे मैं आपको पोस्ट करना चाहूंगा कि त्रुटि लॉग क्या है। PHP में और अपने सर्वर की त्रुटि लॉग में दोनों खोजें

मुझे आपकी प्रतिक्रिया का इंतजार है

— PauloBoaventura
स्रोत
1
अपवाद पहले से ही ऊपर पोस्ट किया गया है, पोस्ट करने के लिए इससे ज्यादा कुछ नहीं है कि यह एक पृष्ठभूमि प्रक्रिया से आ रहा है और यह जो लाइन फेंकता है वह $client->request('GET', ...)(सिर्फ एक नियमित गजल ग्राहक) है।
— ज्वाला
0

जैसा कि यह आपके वातावरण पर छिटपुट रूप से होता है और इसे फेंकने की नकल करना कठिन है RejectionException(कम से कम मैं नहीं कर सकता), क्या आप catchअपने कोड में एक और ब्लॉक जोड़ सकते हैं , नीचे देखें:

try {
    $c = new \GuzzleHttp\Client([
        'timeout' => 0.1
    ]);
    $response = (string) $c->get('https://example.com')->getBody();
} catch (GuzzleHttp\Promise\RejectionException $e) {
    // Log the output of $e->getTraceAsString();
} catch(GuzzleHttp\Exception\RequestException $e) {
    // This occasionally gets catched when a ConnectException (child) is thrown,
    // but it doesnt happen with RejectionException because it is not a child
    // of RequestException.
}

ऐसा क्यों और कब होता है, यह आपको और हमें कुछ विचार देना चाहिए।

— व्लादिमीर
स्रोत
दुख की बात है कि यह नहीं है। मुझे सेंट्री में स्टैकट्रेस मिला क्योंकि इसे पकड़ने के बिना, अंततः यह लारवेल एक्सेप्शन हैंडलर तक पहुंचता है (और सेंटरी को भेजा जाता है)। स्टैक ट्रेस केवल मुझे गज़ल लाइब्रेरी के अंदर गहराई से इंगित करता है, लेकिन मैं यह अनुमान नहीं लगा सकता कि यह एक वादा क्यों है।
— फ्लेम
मेरा एक और जवाब क्यों यह एक वादा मान रहा है के बारे में देखें: stackoverflow.com/a/60498078/1568963
— व्लादिमीर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.