bug
bd dep add fails with a resolution error when the target issue has a different prefix than the source, even though the storage layer's isCrossPrefixDep() is designed to skip target validation for cross-prefix deps.
reproduction
from a project with prefix bt:
bd dep add bt-ssk7 bd-fk1
# error: resolving dependency ID bd-fk1: no issue found matching "bd-fk1"
expected behavior
the dep should be stored with depends_on_id = "bd-fk1". the storage layer already handles this correctly - isCrossPrefixDep() in dolt/dependencies.go detects the prefix mismatch and skips target existence validation. the external: prefix convention works as a workaround (bd dep add bt-ssk7 external:beads:bd-fk1) but bare cross-prefix IDs should work too.
root cause
in cmd/bd/dep.go, the CLI calls resolveIDWithRouting() on the target ID (line 267) before the storage layer ever sees it. resolution tries to find the issue in the local database and fails. the storage layer's cross-prefix handling never gets a chance to run.
the external: prefix bypasses resolution (line 250), but bare cross-prefix IDs like bd-fk1 hit the resolution path and die there.
proposed fix
when resolveIDWithRouting fails for the dep target and the target has a different prefix than the source (via types.ExtractPrefix), fall through and pass the raw ID to AddDependency. same fix needed in dep remove.
working on a PR for this.
bug
bd dep addfails with a resolution error when the target issue has a different prefix than the source, even though the storage layer'sisCrossPrefixDep()is designed to skip target validation for cross-prefix deps.reproduction
from a project with prefix
bt:expected behavior
the dep should be stored with
depends_on_id = "bd-fk1". the storage layer already handles this correctly -isCrossPrefixDep()indolt/dependencies.godetects the prefix mismatch and skips target existence validation. theexternal:prefix convention works as a workaround (bd dep add bt-ssk7 external:beads:bd-fk1) but bare cross-prefix IDs should work too.root cause
in
cmd/bd/dep.go, the CLI callsresolveIDWithRouting()on the target ID (line 267) before the storage layer ever sees it. resolution tries to find the issue in the local database and fails. the storage layer's cross-prefix handling never gets a chance to run.the
external:prefix bypasses resolution (line 250), but bare cross-prefix IDs likebd-fk1hit the resolution path and die there.proposed fix
when
resolveIDWithRoutingfails for the dep target and the target has a different prefix than the source (viatypes.ExtractPrefix), fall through and pass the raw ID toAddDependency. same fix needed indep remove.working on a PR for this.