nats-io/nats-server · error
duplicate service import subject %q, previously used in impo
Error message
duplicate service import subject %q, previously used in import for account %q, subject %q
What it means
AddServiceImport detects a duplicate service import subject (server/accounts.go:2167). Each 'from' subject may only be used once per account for service imports; the error reports the previously registered account and subject.
Source
Thrown at server/accounts.go:2167
}
var atrc bool
dest.mu.RLock()
se := dest.getServiceExport(to)
if se != nil {
rt = se.respType
lat = se.latency
atrc = se.atrc
}
destAccName := dest.Name
dest.mu.RUnlock()
a.mu.Lock()
if a.imports.services == nil {
a.imports.services = make(map[string][]*serviceImport)
} else if dup := a.getServiceImportForAccountLocked(destAccName, from); dup != nil {
a.mu.Unlock()
return nil, fmt.Errorf("duplicate service import subject %q, previously used in import for account %q, subject %q",
from, dup.acc.Name, dup.to)
}
if to == _EMPTY_ {
to = from
}
// Check to see if we have a wildcard
var (
usePub bool
tr *subjectTransform
err error
)
if subjectHasWildcard(to) {
// If to and from match, then we use the published subject.
if to == from {
usePub = true
} else {View on GitHub (pinned to 3a66a489d2)
Solutions
- Use a unique 'from' subject for each service import.
- Remove the existing service import before re-adding it.
- Check for prior registration by inspecting the account's imports.services.
Example fix
// before acc.AddServiceImport(destA, "req", "help") acc.AddServiceImport(destB, "req", "help2") // duplicate "req" // after acc.AddServiceImport(destB, "req2", "help2")
Defensive patterns
Strategy: validation
Validate before calling
if dup := acc.getServiceImportForAccount(destName, from); dup != nil {
return fmt.Errorf("subject %s already imported", from)
} Try / catch
if _, err := acc.AddServiceImport(dest, from, to); err != nil {
if strings.Contains(err.Error(), "duplicate service import") {
// remove old import or choose new subject
}
} Prevention
- Namespace 'from' subjects per service
- Remove stale imports during redeploy
- Keep a registry of used import subjects per account
When it happens
Trigger: Calling AddServiceImport twice with the same 'from' subject on the same account, or reusing a 'from' subject already bound to another destination account.
Common situations: Redeploying services without cleaning up old imports; two services on different accounts mapped to the same local request subject.
Related errors
- service import not found
- failed to create mapping transform for service import subjec
- duplicate call to create subscription for service import
- Error setting up jetstream service imports for account: %v
- service import not authorized
AI-assisted analysis of nats-io/nats-server@3a66a489d2 (2026-09-02).
Data as JSON: /api/errors/bf7aedf96fca074b.
Report an issue: GitHub.