Let's say I have a table of some redundant BLOBs and now I want to deduplicate them. I create a new table t2 with a unique hash field and a trigger to detect hash collisions, however unlikely they may be:

CREATE TABLE t1 (id INTEGER PRIMARY KEY, hash BLOB NOT NULL, data BLOB NOT NULL);
INSERT INTO t1 VALUES(1,unhex(format('31%.62c', '0')),format('%.36760c', 'a'));
INSERT INTO t1 VALUES(2,unhex(format('31%.62c', '0')),format('%.36760c', 'a'));
INSERT INTO t1 VALUES(3,unhex(format('32%.62c', '0')),format('%.36760c', 'b'));
INSERT INTO t1 VALUES(4,unhex(format('32%.62c', '0')),format('%.36760c', 'b'));

CREATE TABLE t2 (id INTEGER PRIMARY KEY, hash BLOB UNIQUE NOT NULL, data BLOB NOT NULL);
CREATE TABLE collisions (oldhash, newhash, old, new);
CREATE TRIGGER t2_collision BEFORE UPDATE OF data ON t2
WHEN old.hash = new.hash AND old.data != new.data
BEGIN
  INSERT INTO collisions (oldhash, newhash, old, new) VALUES (old.hash, new.hash, old.data, new.data);
END;

Now I try to move the data to the new table:

INSERT INTO t2 (hash, data) SELECT hash, data FROM t1 WHERE true ON CONFLICT (hash) DO UPDATE SET data = excluded.data;
SELECT * FROM collisions;

Surprisingly, I notice that while the data has been moved, there is a single collision: the old field consists of 4008 a characters followed by 32752 b characters (no such value is present in the original t1 table), while the new field is 36760 b characters, and both hash fields contain hashes for the new value.

I've tested this on fiddle (3.46.0 2024-04-08 11:50:07) and my local build (3.45.1). The counts are slightly different on my local build (there's 451 bs instead of 4008) but the behavior is otherwise consistent.

I'm not sure why this is happening. Is it expected behavior? Am I misunderstanding something?