current() expects parameter 1 to be array, null given

[pdrolima]

Boa tarde,

Aparentemente, quando não adiciona o numero do telefone no momento em que é gerado o código de checkout, ele cai nesse erro na Notificação. O que é estranho, pois o numero o DDD e o número são inseridos pelo usuário na página do PagSeguro.

< <p>Severity: Warning</p>
< <p>Message:  current() expects parameter 1 to be array, null given</p>
< <p>Filename: Response/Sender.php</p>
< <p>Line Number: 55</p>

[gabriellucius]

Bom dia @webmasterdro

Eu tentei reproduzir aqui seu problema mas não consegui. Você consegue descrever com mais detalhes o que fluxo inteiro até o erro acontecer? (por exemplo, usei o método de checkout tal, depois o método tal e etc) Se possível, passe a versão da biblioteca que você está usando bem como a versão do PHP.

[gabriellucius]

@webmasterdro ainda não consegui replicar aqui. Eu criei uma requisição lightbox sem passar telefone. Adicionei um telefone na tela do lightbox. E consultei a notificação com o método public/Notifications/transactionListener.php passando um código de notificação e funcionou.

Como você está fazendo a consulta de notificação? Acho que não entendi essa parte do seu fluxo.

[rmartignoni]

Estou com o mesmo problema quando faço uma consulta pelo código da transação utilizando o método PagSeguro\Services\Transactions\Search\Code::search

Quando não há um telefone informado no retorno o erro acontece, mais especificamente aqui: vendor/pagseguro/pagseguro-php-sdk/source/Parsers/Response/Sender.php:55

[e59]

Mesma bronca aqui. Muitos problemas para quem quer deixar o log ligado com E_ALL.

Passos para reproduzir:

1. ligar E_ALL
2. Criar um pagamento com o telefone em branco ou um número de celular no lugar do telefone fixo
3. Receber uma notificação deste pagamento.

Dá o notice informado pelo @rmartignoni, especificado acima.

É um simples notice. Ele tenta dar current() num null. Basta checar se o valor está preenchido antes de usar.

[rmartignoni]

@e59, sim, é uma correção simples de se fazer. No entanto, no PHP7 esse problema gera uma exceção, o que interrompe o fluxo da construção do objeto. Neste caso a consulta é invalidada.

É uma pena que um problema relatado a 60 dias ainda não tenha sido corrigido pelos mantenedores do repositório.

[e59]

@rmartignoni Nem diga. Isso gerou disputas para o meu cliente. Estou morto de vergonha. Assim que resolver este problema vou submeter um PR.

[pdrolima]

Eu pensei em adicionar o issettambém. Mas eu não entendi direito, pois se for submetido um número de telefone (00 0000 0000) e o cliente atualizar na página do PagSeguro, durante o pagamento, a notificação não cai nesse erro, agora se não mandar o Phone:

$payment->setSender()->setPhone()->withParameters(
                21,
                980490254
              );

Ele vai cair no erro: current() expects parameter 1 to be array, null given

Meu sistema não tem porque solicitar numero de telefone aos usuários. Pra contornar esse problema, eu coloquei "00 0000 0000"

[rmartignoni]

@webmasterdro acabei esquecendo de lhe responder.

Eu tentei a abordagem que sugeriu (area e numero "0") mas a API recusou o request dizendo que o número informado é inválido.

Acredito que o erro aconteça na consulta justamente pelo fato da informação não existir, logo o isset deve resolver o problema.

[rafael-iop]

Eu estou com o mesmo problema (só testei no sandbox). Notei também que um erro igual a este do telefone também acontece quando não é fornecido um endereço de entrega (que não é obrigatório, visto que estou vendendo um serviço).

O problema aconteceu quando utilizei um endereço de e-mail de comprador que ainda não é cadastrado no PagSeguro (ex: qualquer.coisa@sandbox.pagseguro.com.br). O estranho é que durante o fluxo de pagamento no lightbox o PagSeguro pede para digitar um telefone, então não entendo o motivo desta informação não estar sendo salva na transação.

Abaixo a resposta da API ao consultar a notificação (apenas o nodo sender):

<sender>
        <email>qualquer.coisa@sandbox.pagseguro.com.br</email>
</sender>

[rafael-iop]

@gabriellucius Alguma previsão para aprovar o PR #57 enviado pelo @rmartignoni?

[mcspronko]

Hi, any updates when the #57 will be merged and released? Thanks.

[adrianolls]

1 ano se passou e nenhuma solução foi aplicada no repositório para o problema, mesmo após contribuição do @rmartignoni.

[geekcom]

Obrigado pela contribuição pessoal, @rmartignoni, vou usar a sugestão da PR 57 que você abriu que para resolver esse problema, como o branch developer não estava mais disponível vou usar o trecho de código por aqui mesmo, sem dar merge em sua PR, já junto isso ao branch Master também.

[geekcom]

Resolvido com o PR 157

[roquesz]

Estou exatamente com o mesmo problema, agora é com o nome. Vendas feitas pela minizinha não tem nome de usuário, nem tão pouco email. Vou abrir um PR para ser analisado @geekcom