= Hackney-verzoek (via HTTPost) retourneert geen resultaat tijdens uitvoering. =

Hallo, ik heb een eenvoudige chatbot geschreven in elixer. Een van mijn usecases is om een ​​vraag naar een bepaalde url te sturen. Ik verwachtte dat de queryserver een beetje traag zou reageren (enkele seconden). Ik heb mijn code geschreven en in mijn machineverbinding werkt de querycode normaal. Maar toen ik mijn applicatie op een VPS implementeerde, retourneerde de vraag gewoon geen antwoord, geen fout of een bericht

Dit maakt me een beetje gek omdat ik geen enkele manier heb om het te debuggen, aangezien de oproep zelf vast lijkt te zitten en niet voor onbepaalde tijd terugkeert. Het handmatig uitvoeren van curl in de container werkt, het uitvoeren van het verzoek binnen iex dat het lopende knooppunt op afstand bestuurt, werkt wel, maar in het live-systeem werkt het niet. Zou iemand mij misschien kunnen helpen? Hieronder is het fragment van de code in kwestie:
http_config = [ hackney: [pool: :tl], recv_timeout: 30_000, timeout: 30_000 ] met {:ok, body}<- Jason.encodesrc"=>query {: ok, %HTTPoison.Response{body: body}}<- HTTPoison.post(url, body,http_config), {:ok, result"=>result, "src_lang"=>src_lang}}<- Jason.decode(body) do result end |>IO.inspect(label: :result)
Bewerken: ik heb de vertegenwoordigende inspectielijn toegevoegd. Soms werkt dit fragment normaal, soms niet. Toen ik dit programma hostte in de spotgoedkope speciale VPS van mijn vriend voor black friday, had ik dit probleem nooit. Maar toen ik naar Vultr verhuisde, kreeg ik dit probleem. Ik heb het ook geprobeerd op een andere VPS-provider die ik in het verleden heb gebruikt (ramnode) en heb hetzelfde probleem

Het eerste dat me opvalt, is dat je with-verklaring geen else-clausule heeft, dus je zult niet zien waar het faalt

Probeer een else en patroonovereenkomst toe te voegen aan de
{:error, cause} tuple en schrijf het naar log met sth zoals `Logger.error("Mislukte http post: #{inspect error
Dan zou je moeten kunnen zien waarom het niet lukt

p.s. het werkt waarschijnlijk op een externe shell op uw lokale systeem omdat de netwerkaanroep wordt gedaan op de lokale machine (die het externe knooppunt uitvoert) in plaats van op de implementatieserver. Om ervoor te zorgen dat de netwerkoproep plaatsvindt op de externe server, spawnt u een proces op het externe knooppunt (Node.spawn, bijvoorbeeld) dat de http-oproep doet


Ah, het spijt me dat het fragment niet het hele verhaal vertelt, maar daarna, wat er ook gebeurt, heb ik een loggerregel die aangeeft dat de opdracht is voltooid, en uiteindelijk als het resultaat {:error, _ is } Ik registreer het. Maar in mijn geval wordt de regel die aangeeft dat de functie is voltooid, nooit gebeld, het is net als het postverzoek dat gewoon vastzit in afwachting van de hand die nooit is teruggekeerd

Ik gebruik releases en ik voer de release binary remote uit op de deploy-server om verbinding te maken met het huidige actieve knooppunt.