(eon, identityPrefix, sender) is no longer a unique key after the identity computation change to include the trigger definition. See: https://github.com/shutter-network/rolling-shutter/pull/662/changes
Shutter API was updated to use (eon, identity) as the primary key, and this change mirrors that in the Keyper DB. See: shutter-network/shutter-api#95
Example that exposed the issue: in the same eon, we registered triggers with the same identityPrefix and sender, but with different triggerDefinition. After identity computation started including triggerDefinition, these registrations produced different identities. With the old DB key (eon, identityPrefix, sender), they could be merged/overwritten at keying/upsert level, causing one trigger not to decrypt as expected.
(eon, identityPrefix, sender) is no longer a unique key after the identity computation change to include the trigger definition. See: https://github.com/shutter-network/rolling-shutter/pull/662/changes
Shutter API was updated to use (eon, identity) as the primary key, and this change mirrors that in the Keyper DB. See: shutter-network/shutter-api#95
Example that exposed the issue: in the same eon, we registered triggers with the same identityPrefix and sender, but with different triggerDefinition. After identity computation started including triggerDefinition, these registrations produced different identities. With the old DB key (eon, identityPrefix, sender), they could be merged/overwritten at keying/upsert level, causing one trigger not to decrypt as expected.