Inconsistent behaviour with onConflictDoUpdate

[GregTheGreek]

Version

0.8.10

Current behavior

Ran into an issue where onConflictDoUpdate did not do what was expected. I have two events, both which update the same table (removed a lot of code, and hid some fields). I noticed that I was always experiencing empty table values where the update should have worked, and appended the correct data if a row already existed that matched.

To solve this I had to change the onConflictDoUpdate to:

.onConflictDoUpdate((row) => {
  ...row,
  // update fields
});

Schema:

export const Transaction = onchainTable(
  "transaction", (t) => ({
  
    // from chain A event
    originChainId: t.integer(),
    depositId: t.integer(),
    destinationChainId: t.integer(),
    originTxHash,
    
    // from chain B event
    destinationTxHash: t.hex(),
  }),
  (table) => ({
    pk: primaryKey({ columns: [table.originChainId, table.depositId] })
  })
);

Processing logic:

ponder.on("event", async ({ event, context }) => {

  await context.db.insert(Transaction).values({
    depositId: Number(event.args.depositId),
    originChainId: context.network.chainId,

    // Non primary key fields
    originTxHash: event.transaction.hash,
  })
  .onConflictDoUpdate({
    originTxHash: event.transaction.hash,
  }));
});

ponder.on("event", async ({ event, context }) => {

  await context.db.insert(Transaction).values({
    depositId: event.args.depositId,
    originChainId: Number(event.args.originChainId),

    // Non primary key fields
    destinationTxHash: event.transaction.hash
  })
  .onConflictDoUpdate({
    destinationTxHash: event.transaction.hash
  }));
});

Expected behavior

No response

Steps to reproduce

No response

Link to repository

No response

Anything else?

No response

[kyscott18]

Hey, sorry about this issue. Have a few more questions:

• when you say "experiencing empty table values where the update should have worked", do you mean that the row only contained the column that was updated after onConflictDoUpdate was used? Or the row was deleted from the table?
• where are you noticing the bug (are you doing a find in a different indexing function?)