よくある Laravel エラーを思い出してください

私はこの期間、Laravel フレームワークを使用してきましたが、その中にはデバッグが難しい問題がいくつかありましたので、皆さんの参考になればと思います。寄り道は避けてください。そうすれば無駄には書かれませんでした。

エラー: 「トランザクション内では PDO インスタンスをスワップできません」

Laravel ソース コードをクエリすると、setPdo メソッドで例外がスローされたことを確認できます:

<?phppublic function setPdo($pdo){    if ($this->transactions >= 1) {        throw new RuntimeException("            Can't swap PDO instance while within transaction.        ");    }    $this->pdo = $pdo;    return $this;}?>

文字通り理解すると、このエラーは、トランザクションが有効になっている間にデータベース接続が切り替えられるために発生します。ただし、データベース接続がコード内で明示的に切り替えられていない場合でも、このエラーが発生することがあります。たとえば、クエリ ステートメントの実行時にエラーが発生した場合、システムは tryAgainIfCausedByLostConnection メソッドを使用して、問題の原因が接続の喪失であるかどうかを判断します。その場合、システムは再接続時に reconnect メソッドを使用して再接続します。 setPdo メソッドが呼び出されるクリーンアップ作業を通じていくつかの機能を実行します。

原因と結果を整理すると、問題の解決方法が自然にわかります。ネットワークの状況を確認し、データベース接続が失われた理由を確認します。これは、特定のデバイスに問題がある可能性があります。特定のタイムアウトの設定が不適切なことが原因である可能性があります。比較的汚い解決策は、クエリを実行する前に DB::reconnect() メソッドを実行してデータベースに再接続することです。

エラー: "ジョブ を削除できません: NOT_FOUND"

この問題は実際には Laravel とは関係ありませんが、キュー サービス Beanstalk が原因で発生します。

Beanstalk

この問題を解決するには、まずメッセージのライフサイクルを理解する必要があります。メッセージはキューに入れられると READY 状態になります。同時に、このメッセージが消費されると、メッセージは RESERVED 状態に入り、実行が許可される時間を示す TTR (実行時間) タイマーに関連付けられます。消費時間が長すぎて TTR より長い場合、システムはコンシューマがハングアップしたとみなして、メッセージを RESERVED 状態から READY 状態に戻し、再処理のために別のコンシューマに渡します。したがって、同じメッセージが複数のコンシューマによって処理される可能性があります。処理を完了した最初のコンシューマはメッセージを通常どおり削除できますが、残りのコンシューマはメッセージを削除するときに削除できないエラーを報告します。

解決策は簡単です。まず、TTR 設定が小さすぎないようにする必要があります。次に、Beanstalk は、実行時間が長すぎる問題を解決するために、実際には特別なタッチ コマンドを提供します。同じメッセージが複数のコンシューマによって同時に処理される状況を避けるために、ロックがアプリケーション レベルで使用される場合があります。

エラー: "モデルのクエリ結果がありません"

Laravel の読み書き分離がアクティブ化されている場合、コンシューマーはメッセージの処理時に同様のエラーを受け取る可能性があります。潜在的に問題のあるキューコマンドは次のようになります:

<?phpclass Foo extends Command implements SelfHandling, ShouldBeQueued{    use InteractsWithQueue, SerializesModels;    protected $bar;    public function __construct($id)    {        $this->bar = Bar::find($id);    }    public function handle()    {        // $this->bar    }}?>

明らかに、Laravel の読み書き分離がオンになっている場合、find はマスターとスレーブの遅延により、対応するデータをクエリできない可能性があります。これを分析すると、おそらく次のように記述を変更します:

<?phpclass Foo extends Command implements SelfHandling, ShouldBeQueued{    use InteractsWithQueue, SerializesModels;    protected $bar;    public function __construct($id)    {        $this->bar = Bar::onWriteConnection()->find($id);    }    public function handle()    {        // $this->bar    }}?>

つまり、クエリは Laravel の onWriteConnection メソッドを通じてメインサーバー上で修正されますが、実際には無効です。問題の核心は、逆シリアル化中にシステムがサーバーから findOrFail を 1 回呼び出すことです。

<?phpprotected function getRestoredPropertyValue($value){    return $value instanceof ModelIdentifier        ? (new $value->class)->findOrFail($value->id) : $value;}?>

フレーム内では HACK できないため、onWriteConnection は意味がありません。実際、問題を別の角度から見ると、シリアル化するときにデータベース オブジェクトを属性として使用しないように注意してください。

<?phpclass Foo extends Command implements SelfHandling, ShouldBeQueued{    use InteractsWithQueue, SerializesModels;    protected $id;    public function __construct($id)    {        $this->id = $id;    }    public function handle()    {        $bar = Bar::onWriteConnection()->find($this->id);    }}?>

上記は、私が遭遇した代表的なエラーのいくつかです。何か質問はありますか? 、一緒にコミュニケーションをとるのもいいかもしれません。