Closed warlof closed 2 years ago
the id is a unique key, but in the place where we query for an existing itme, there is an additional check for the corporation
This is especially weird because I believe this code is preceded with a call to wipe all of the given corporations assets, so duplicate keys shouldn't be possible.
This occurred likely as a result of the ESI failure early 2022, and was ultimately resolved by manually wiping the effected table, though a fix would be wise as I do not have an easy way to know if other corporation/character IDs have similarly corrupt data.
Issue was still extant on the following versions (but has since been manually worked around so I cannot re-test): PHP Version: 7.4.27 SeAT API Installed: v4.7.0 SeAT Console Installed: v4.8.0 SeAT Eve API Installed: v4.16.0 SeAT Notifications Installed: v4.3.1 SeAT Services Installed: v4.2.0 SeAT Web Installed: v4.17.0 OS: Docker on CentOS 7 host
The file in question. Ignore my earlier comments about corporation assets wiping, that was my own misunderstanding.
https://github.com/eveseat/eveapi/blob/master/src/Jobs/Assets/Corporation/Assets.php#L112
There may be a solution in replacing firstOrNew
with updateOrCreate
as appropriate.
$model = CorporationAsset::updateOrCreate([
'corporation_id' => $this->getCorporationId(),
'item_id' => $asset->item_id,
], [
// Map in new changed values here
]);
Or potentially adding protected static $guarded = ['item_id'];
to the file below, and removing protected static $unguarded = true;
https://github.com/eveseat/eveapi/blob/master/src/Models/Assets/CorporationAsset.php#L148
To me, the issue is much tied to the table primary key (set to item_id) which is distinct from the unicity check (corporation_id + item_id)
I figure the error occurred on an item which has been transferred across corporation.
To me, the issue is much tied to the table primary key (set to item_id) which is distinct from the unicity check (corporation_id + item_id)
I figure the error occurred on an item which has been transferred across corporation.
pretty sure that is it. Is there even any reason for the corporation check?
check should match table primary key so, actually, nope :)
To me, the issue is much tied to the table primary key (set to item_id) which is distinct from the unicity check (corporation_id + item_id)
I figure the error occurred on an item which has been transferred across corporation.
This is very possible. It occurred on one of my holding corps, and I have multiple corporations that are tracked and regularly exchange items between them.