Whether a DBL catalog row already accounts for a local project — by exact projectId match, or,
failing that, by the startsWith(dblEntryUid) convention.
The prefix branch is a best-effort fallback, not an invariant. A resource project's id is
unrelated to the DBL entry it was installed from: ParatextData records the entry uid in the
project's settings and matches on that, so the prefix holds for many installed resources and not
for others. The projectId the backend reports is authoritative, so the exact match is tried
first — but the prefix test is a fallthrough, not an else, so a row naming project A can still
claim a prefix-sharing project B. buildLocalNonDblResources depends on that today, which is
what makes tightening it a behaviour change rather than a cleanup. See
adr-dbl-install-status-from-backend.
Both branches require the row to have been reconciled against disk at least once (installed, or
a non-empty projectId). A never-synced row carries installed: false, projectId: '', and
''.startsWith('') is true for every string, so trusting such a row would let a stale entry for
a DBL-reassigned UID hide a local project whose real UID still matches.
Producers on both sides of the picker consult this — the one that decides which local projects
are NOT already in the catalog, and the one that decides which catalog row describes a downloaded
project. They must agree, or a project is claimed by one and disowned by the other.
Whether a DBL catalog row already accounts for a local project — by exact
projectIdmatch, or, failing that, by thestartsWith(dblEntryUid)convention.The prefix branch is a best-effort fallback, not an invariant. A resource project's id is unrelated to the DBL entry it was installed from: ParatextData records the entry uid in the project's settings and matches on that, so the prefix holds for many installed resources and not for others. The
projectIdthe backend reports is authoritative, so the exact match is tried first — but the prefix test is a fallthrough, not anelse, so a row naming project A can still claim a prefix-sharing project B.buildLocalNonDblResourcesdepends on that today, which is what makes tightening it a behaviour change rather than a cleanup. Seeadr-dbl-install-status-from-backend.Both branches require the row to have been reconciled against disk at least once (
installed, or a non-emptyprojectId). A never-synced row carriesinstalled: false, projectId: '', and''.startsWith('')is true for every string, so trusting such a row would let a stale entry for a DBL-reassigned UID hide a local project whose real UID still matches.Producers on both sides of the picker consult this — the one that decides which local projects are NOT already in the catalog, and the one that decides which catalog row describes a downloaded project. They must agree, or a project is claimed by one and disowned by the other.