Problem Surfaced
The piece_cleanup job began throwing the following error for 32 deals:
Error: StorageContext resolveByDataSetId failed: Data set <data_set_id> is not owned by
0x305025D07c1DEe47F25a4990179eFf2becddCA0B (owned by 0xa5F90bc2AA73a2E0Bad4D7092a932644d5dD5d71)
The Synapse SDK's resolveByDataSetId enforces wallet ownership when performing piece deletion. The current process wallet (0x305025D) does not own those data sets on-chain. They were created by the old wallet (0xa5F90bc). Cleanup therefore fails permanently for all 32 affected deals under the current process.
What We Confirmed from the Database
Step 1 — on-chain check: The new wallet (0x305025D) legitimately owns data sets with IDs greater than 721 on-chain. Data set IDs below 721 in dealbot db belong to the old wallet (0xa5F90bc).
Step 2 — DB query: Querying deals tagged with the new wallet but referencing a data set ID below the ownership boundary surfaced exactly 32 mismatched deals:
SELECT id, sp_address, data_set_id, piece_id, created_at
FROM deals
WHERE wallet_address = '0x305025D07c1DEe47F25a4990179eFf2becddCA0B'
AND data_set_id::bigint < 721
ORDER BY created_at;
Result: 32 deals, all created between 2026-04-02 19:06:17.713129+00 and 2026-04-02 20:49:04.935386+00.
| Field |
Value |
wallet_address (DB) |
0x305025D07c1DEe47F25a4990179eFf2becddCA0B (new wallet) |
data_set_id range (DB) |
< 721 — on-chain owned by 0xa5F90bc2AA73a2E0Bad4D7092a932644d5dD5d71 (old wallet) |
created_at window |
2026-04-02 19:06:17+00 → 2026-04-02 20:49:04+00 |
| Count |
32 deals |
The drift window aligns precisely with two infrastructure commits:
- b549bc8 — 2026-04-02 18:31 GMT+00 — env vars updated:
WALLET_ADDRESS changed to new wallet, WALLET_PRIVATE_KEY removed, SESSION_KEY_PRIVATE_KEY added
- 5da1cac — 2026-04-02 20:58 GMT+00 — full production deployment
Proposed Fix
Immediate: patch the 32 affected rows in the database
Because piece_cleanup filters candidates by wallet_address, these 32 deals will never be selected for cleanup by the current process. The recommended remediation is to mark them as cleaned up:
UPDATE deals
SET wallet_address = '0xa5F90bc2AA73a2E0Bad4D7092a932644d5dD5d71', cleaned_up = true, cleaned_up_at = NOW()
WHERE wallet_address = '0x305025D07c1DEe47F25a4990179eFf2becddCA0B'
AND data_set_id::bigint < 721
AND cleaned_up = false;
Important: The pieces from old wallet are already deleted on-chain.
Further Investigation Required
The commit at 18:31 migrated the system from direct-key mode (WALLET_PRIVATE_KEY) to session-key mode (SESSION_KEY_PRIVATE_KEY), and updated WALLET_ADDRESS to the new wallet (0x305025D).
In session-key mode, WALLET_ADDRESS is the single source of truth for both the SDK's on-chain identity and the DB stamp:
// synapse-factory.ts — session-key mode
const readClient = createClient({
account: { ...sessionKeyAccount, address: walletAddress }, // from blockchainConfig.walletAddress
});
// deal.service.ts:316
deal.walletAddress = this.blockchainConfig.walletAddress; // same source
A clean pod restart with both changes applied atomically would be fully consistent — readClient.account.address and deal.walletAddress always agree. There is no obvious code path in a clean restart that produces the drift.
Problem Surfaced
The
piece_cleanupjob began throwing the following error for 32 deals:The Synapse SDK's
resolveByDataSetIdenforces wallet ownership when performing piece deletion. The current process wallet (0x305025D) does not own those data sets on-chain. They were created by the old wallet (0xa5F90bc). Cleanup therefore fails permanently for all 32 affected deals under the current process.What We Confirmed from the Database
Step 1 — on-chain check: The new wallet (
0x305025D) legitimately owns data sets with IDs greater than 721 on-chain. Data set IDs below 721 in dealbot db belong to the old wallet (0xa5F90bc).Step 2 — DB query: Querying deals tagged with the new wallet but referencing a data set ID below the ownership boundary surfaced exactly 32 mismatched deals:
Result: 32 deals, all created between
2026-04-02 19:06:17.713129+00and2026-04-02 20:49:04.935386+00.wallet_address(DB)0x305025D07c1DEe47F25a4990179eFf2becddCA0B(new wallet)data_set_idrange (DB)< 721— on-chain owned by0xa5F90bc2AA73a2E0Bad4D7092a932644d5dD5d71(old wallet)created_atwindow2026-04-02 19:06:17+00→2026-04-02 20:49:04+00The drift window aligns precisely with two infrastructure commits:
WALLET_ADDRESSchanged to new wallet,WALLET_PRIVATE_KEYremoved,SESSION_KEY_PRIVATE_KEYaddedProposed Fix
Immediate: patch the 32 affected rows in the database
Because
piece_cleanupfilters candidates bywallet_address, these 32 deals will never be selected for cleanup by the current process. The recommended remediation is to mark them as cleaned up:Further Investigation Required
The commit at 18:31 migrated the system from direct-key mode (
WALLET_PRIVATE_KEY) to session-key mode (SESSION_KEY_PRIVATE_KEY), and updatedWALLET_ADDRESSto the new wallet (0x305025D).In session-key mode,
WALLET_ADDRESSis the single source of truth for both the SDK's on-chain identity and the DB stamp:A clean pod restart with both changes applied atomically would be fully consistent —
readClient.account.addressanddeal.walletAddressalways agree. There is no obvious code path in a clean restart that produces the drift.