Wrong contact name

[louie96-svg]

In version 3.2.1, the contact names are wrong when exporting. When I export a thread from one contact, the name in the HTML export appears as another contact's name.

[ReagentX]

What command are you running when invoking imessage-exporter? Is the contact detail shared between multiple contacts? What is the output of imessage-exporter when running with the --diagnostics flag?

[louie96-svg]

Ok. Is there an easy way to downgrade to older versions?

[louie96-svg]

Also...I have two Macs. Both have same issue with the same contact. Contact is an iCloud contact if that helps any.

[louie96-svg]

And...a little more info. If I use the "wrong" contact name in the -t option when exporting, I get all threads from both the correct and wrong contact. So somewhere this "wrong" name is being associated with the contact I really want to export, just not sure where, and how.

[ReagentX]

You can install a specific version using cargo install imessage-exporter --version 3.2.0 if you want (or simply download the 3.2.0 release directly).

Given the behavior you describe with the -t flag, I suspect something in your iMessage database is causing imessage-exporter to map both contacts together. This can happen if the person_centric_id maps them together (you would have to manually check the handle table to know if this is the case) or by exact equality of the id string (email or phone number). The former folds every row sharing a person_centric_id into the same concatenated ID string before deduping; the latter just compares the resulting strings for exact equality and assigns stable numeric IDs in rowid order.

If you are able to peek into the messages database (located at ~/Library/Messages/chat.db), you could check if there is a relationship between the IDs, either with a person_centric_id populated or an exact string match for both ids (unlikely). This would inform my search for where this bug resides.

[ReagentX]

For more advanced debugging, we would want to log:

• participants: HashMap<i32, String> (from Handle::cache) for the raw handle_id data.
• Config.real_participants for the deduplicated mapping.
• Config.participants[deduped_id] to see which handle_ids got bound to that Name.

[louie96-svg]

Ok, thanks. However, I think I have pinpointed why this issue is happening...in my ~/Library/Application Support/AddressBook/Sources directory I have two subdirectories each containing an AddressBook-v22.abcddb file. If I peek into that using sqlite, I see the correct contact name/phone number in one file, and the wrong contact name with same phone number in the other. Not sure why I would have two different address book files, and why is it not causing issues with my Contacts app.

[ReagentX]

Ok, this answers your question then. imessage-exporter scans all of the address book files that it can find:

imessage-exporter/imessage-exporter/src/app/contacts.rs

Lines 377 to 394 in d52323a

	// MARK: macOS Dirs
	/// Scans the macOS Contacts Sources directory (`~/Library/Application Support/AddressBook/Sources`)
	/// for AddressBook-v22.abcddb database files.
	fn find_macos_addressbook_db_paths() -> Vec<PathBuf> {
	let mut results = Vec::new();
	if let Ok(entries) = fs::read_dir(macos_sources_dir()) {
	for entry in entries.flatten() {
	let path = entry.path();
	if path.is_dir() {
	let db_path = path.join("AddressBook-v22.abcddb");
	if db_path.is_file() {
	results.push(db_path);
	}
	}
	}
	}
	results
	}

imessage-exporter/imessage-exporter/src/app/contacts.rs

Lines 134 to 142 in d52323a

	for db_path in find_macos_addressbook_db_paths() {
	if let Ok(local_conn) = Connection::open(&db_path) {
	let sub = Self::build_from_macos(&local_conn)?;
	for (k, v) in sub.index {
	upsert_best(&mut idx, k, &v);
	}
	}
	}

imessage-exporter/imessage-exporter/src/app/contacts.rs

Lines 59 to 62 in d52323a

	/// Simple scoring: 1 point for first name, 1 point for last name
	fn score(&self) -> u8 {
	u8::from(!self.first.is_empty()) + u8::from(!self.last.is_empty())
	}

So for a given normalized phone/email key, the first DB that has that key sets an entry. Any later DB with the same key will either replace it if incoming.score() is higher, or be ignored if incoming.score() is lower or equal. The latter of which is likely happening to you.

[ReagentX]

I am not sure if there is a way to determine which AddressBook-v22.abcddb is the authoritative one, but knowing that would in theory let us prioritize the authoritative DB over the subsequent ones.

[louie96-svg]

Ok, I think one of them is old on my Mac, I am going to try and delete it (backup) and see what happens to my Contacts. In any case, think this discussion can be closed as don't think there is anything on your side to do. Thanks again for staying in the conversation. BTW, this is an excellent utility and very useful!!

[ReagentX]

No problem, I wanted to understand what was going on so I could fix it if necessary. I do think that this logic should be improved–we want to trust the "authoritative" database over any others found–I just don't know yet how to determine which it might be. We could also introduce a log to emit conflicted contact details.