Table Information not clearing on pagination/search

[HawtDogFlvrWtr]

Laravel 9.19 laravel-table 5.3.1 livewire 2.12.6

I have a table of random data (150k records) and if I paginate over and over, the table length on each pagination will grow. It doesn't always happen, which is odd. If I watch the network traffic that's sent back, only the records that should be displayed are in there. It's almost like the datatable isn't clearing the previous table and it's just prepending the correct data and leaving the old data.

All I do to reproduce, is click the max pagination and select a random previous pagination, and it does it. Attached is photos of what i'm talking about. The table return from the backend is correct. The display is wrong. It won't correct the table unless I refresh, but then I lose pagination. On smaller tables it works fine. I initially thought it was the search wrong for PGSQL but because the data being returned is correct, it's truly a display issue with the table not refreshing. It also doesn't appear to happen when the table has few records. Also notice on the pagination one, how the results count at the bottom is overlapping with old results and new. Its definitely an issue with refresh not happening properly.

I also notice that when I search for an item, the records that match search are at the top, but a bunch of random records are at the bottom. It's displaying the correct record count on search filter, but the page refreshes with the records at the top, but random previous records below.

Pagination Issue:

Search Issue:

Table & Migration:

####### TABLE #######
<?php

namespace App\Tables;

use App\Models\XXXXsearch;
use Illuminate\Support\Facades\Auth;
use Okipa\LaravelTable\Abstracts\AbstractTableConfiguration;
use Okipa\LaravelTable\Column;
use Illuminate\Database\Eloquent\Builder;
use Okipa\LaravelTable\RowActions\DestroyRowAction;
use Okipa\LaravelTable\RowActions\EditRowAction;
use Okipa\LaravelTable\Table;

class SearchTable extends AbstractTableConfiguration
{
    protected function table(): Table
    {
        return Table::make()
            ->model(XXXXsearch::class);
    }

    protected function columns(): array
    {
        return [

            Column::make('x')->title('x')->searchable()->sortable(),
            Column::make('xx')->title('xx')->searchable()->sortable(),
            Column::make('xxx')->title('xxx')->sortable(),
            Column::make('xxxx)->title('xxxx')->searchable()->sortable(),
            Column::make('xxxxx')->title('xxxxx')->searchable()->sortable(),
            Column::make('xxxxxx')->title('xxxxxx')->searchable()->sortable(),
            Column::make('file_ingested_on')->title('Created On')->sortable(),
            Column::make('last_updated_on')->title('Updated On')->sortable()->sortByDefault('desc'),
        ];
    }

    protected function results(): array
    {
        return [
            // The table results configuration.
            // As results are optional on tables, you may delete this method if you do not use it.
        ];
    }
}

##### MIGRATION #####
<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::connection('xxxx_schema')->create('search', function (Blueprint $table) {
            $table->id('xxxxxxxx')->constrained('xxxxxxxx');
            $table->string('x')->nullable();
            $table->string('xx')->nullable();
            $table->integer('xxx')->nullable();
            $table->string('xxxx')->nullable();
            $table->string('xxxxx')->nullable();
            $table->string('xxxxxx')->nullable();
            $table->string('xxxxxxx')->nullable();
            $table->date('file_ingested_on')->nullable();
            $table->date('last_updated_on')->nullable();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('xxxxsearches');
    }
};

[HawtDogFlvrWtr]

FIX: tldr; if you use a custom column name for the id in your migration $table->id('column_name'), you need to explicitly specify the primary key in the model so getKey() actually works. Here's what you put in the model: protected $primaryKey = 'column_name';

The Long:

I figured out what it was after checking out the livewire documentation about wire:key needing to be unique or wonkieness will ensue. After reviewing the updates on page, I noticed that the wire:key was lacking the record id on each row, so there were duplicates that would clobber things. If you look above, I use a custom id column name instead of "id". When you use something other than "id" as the primary key for the table, I guess $model->getKey() doesn't know where to look, so it returns null. For future reference by anyone pulling their hair out like I was, here are some pretty screenshots to look for :D

Notice row- vs row-x

Missing id:

With Id:

[HawtDogFlvrWtr]

Closing this ticket