Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

A name pushed in a statements source is an identity, but resolution still proposes it as a duplicate

Open
  • Is something wrong?
#1,293 7 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
18/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
postgresql, rust
Domain
backend, databases

Research direction

This is a design proposal, so the first step is agreeing a direction in the thread, not writing code. Read decision 3 of 0054, then the write-time resolution paths named in the issue: propose_by_name_vector, containment_reviews (the LIKE patterns) and resolve_by_name with SIM_ATTACH. Done means the maintainers accept or reshape the proposal, and the escaping fix in item 3 can then be split into a small PR.

Written by the indexing model from the issue text.

Description

enhancement

Thank you for 0054. Pushing statements works well for us; one side effect has grown large enough that I'd like to agree a direction here before writing any code.

What we see. Our backend pushes machine-named entities through a statements source, one knowledge base per repository: owner/repo:specs/x/spec.md (a Spec), owner/repo:specs/x/spec.md#s0003 (a Statement), owner/repo:src/a.test.ts::adds two (a Test), owner/repo:src/a.ts#parseDate (a definition), and so on. Each name is an identity we already know is unique. Every one still goes through write-time resolution (0054 decision 3, "continues unchanged"), and the duplicates queue fills with pairs that can never be the same thing:

  • name vectors (propose_by_name_vector): every name shares the owner/repo: prefix, so unrelated entities clear 0.60 easily; up to 8 pairs per mention, across classes, since the type filter only knows the person/event/org/place families;
  • containment (containment_reviews): …::adds inside …::adds two, #foo inside #fooBar; the LIKE patterns are not escaped, so an _ in a name matches any character;
  • single-candidate split (resolve_by_name, cosine below SIM_ATTACH): the same file named in two payloads with different context becomes two entities with one name.

#1192 and #1199 improve the exact-name paths with several candidates and the automatic merge; neither touches these three.

What would help. An entity named in a statements push is a client's identity claim, so resolution could treat it as one:

  1. a pushed named entity attaches to the unique case-insensitive exact-name entity of its class (or of no class) whatever the profile score, and is created only when there is none;
  2. a pushed named entity is never proposed by name vector or containment;
  3. independently useful for prose too: escape % and _ in the containment LIKE patterns, and let propose_by_name_vector skip pairs whose classes are declared disjoint.

Prose extraction keeps every path it has today. This would be a revision of 0054 decision 3 (and fits the direction #725 describes for write-time resolution). If you'd prefer it opt-in per source (say a config.names_are_identities flag), that works for us too.

Happy to write the revision here first and then send it as small PRs, one at a time, if this direction is welcome.

Related: 0054, 0041, #1192, #1199, #725.

Dominant language
Rust
Stars
8.1k
Forks
1.1k
Avg merge
21h 2m
Merged PRs (30d)
263

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from deeplethe/utopia

All issues in deeplethe/utopia

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.