Regression in v1.2.X: Nested Relation() fails when using struct composition for shared fields and relations

[fibonaxi]

Hi, I’ve run into a regression after upgrading from Bun v1.1.14 to v1.2.14 involving struct composition for shared fields and relationships.

I use composition in my entity definitions to embed common fields and relationships. Here's a simplified version of the setup:

Common fields:

type IDField struct {
	ID int64 `bun:",pk,unique,autoincrement"`
}

type AgentRelation struct {
	AgentID int64  `bun:",nullzero"`
	Agent   *Agent `bun:"rel:belongs-to,join:agent_id=id"`
}

type LeadRelation struct {
	LeadID int64 `bun:",nullzero"`
	Lead   *Lead `bun:"rel:belongs-to,join:lead_id=id"`
}

type BusinessRelation struct {
	BusinessID int64     `bun:",nullzero"`
	Business   *Business `bun:"rel:belongs-to,join:business_id=id"`
}

Models:

type Agent struct {
	IDField
	BusinessRelation

	Associations []*Link `bun:"rel:has-many,join:id=agent_id"`
}

type Business struct {
	IDField
	LeadRelation

	// other fields
}

type Lead struct {
	IDField
	BusinessRelation

	// other fields
}

type Link struct {
	IDField
	AgentRelation
	LeadRelation

        // other fields
}

Query:

var agents []entity.Agent
if err := db.NewSelect().
	Model(&agents).
	Relation("Associations.Lead.Business").
	Scan(ctx); err != nil {
	panic(err)
}

Result: It panics with

sql: Scan error on column index 6, name "lead__business__id": bun: Link does not have column "lead__business__id"

Possible Cause

The bug appears to be in how Bun v1.2 resolves embedded/composed structs during relation joins — particularly when chaining multiple levels (e.g. Agent → Link → Lead → Business)

Thanks in advance!

[j2gg0s]

Thanks for the feedback; it's very detailed.

Circular dependencies exist between the entities,
causing an unfully initialized Business object to be used during Link initialization.

This problem appears very difficult to solve.
Could you please consider addressing this severe circular dependency?

[fibonaxi]

Thanks for the response.

While I understand the complexity, is quite common in real-world systems that entities are naturally connected both ways (please note that I'm not loading them in a way that create circular dependency). Being able to navigate and query these relations in both directions is essential for building meaningful features (e.g., audit trails, ownership tracking, analytics).

Also this was something that was working in 1.1.X versions, so something in the way relations are being scanned in the new version seems to break this previously working code.

[fibonaxi]

Another thing that I found is that if in the Lead entity I replace BusinessRelation by a copy that only differs in the name, let's call it BusinessRelationCopy, the code works:

type BusinessRelationCopy struct {
	BusinessID int64     `bun:",nullzero"`
	Business   *Business `bun:"rel:belongs-to,join:business_id=id"`
}

type Lead struct {
	IDField
	BusinessRelationCopy

	// other fields
}

So IMO the issue could be in the way embedded structs are handled in the new version...

[j2gg0s]

While I understand the complexity, is quite common in real-world systems that entities are naturally connected both ways (please note that I'm not loading them in a way that create circular dependency). Being able to navigate and query these relations in both directions is essential for building meaningful features (e.g., audit trails, ownership tracking, analytics).

This is a circular dependency, which is likely a rare or unintended scenario.
Lead->BusinessRelation->Business->LeadRelation->Lead

Also this was something that was working in 1.1.X versions, so something in the way relations are being scanned in the new version seems to break this previously working code.

Version v1.1.14 does not recursively process StructField, so it doesn’t encounter this issue — however, it has other problems.

Another thing that I found is that if in the Lead entity I replace BusinessRelation by a copy that only differs in the name, let's call it BusinessRelationCopy, the code works:

The issue arises because we first attempt to create the table structure for Business,
and during that process, we realize that the table structure for Lead also needs to be created.
During the process of creating the Lead table structure,
we then discover that Business is needed again — but at this point, we’re using a partially constructed version of it.

You can try adjusting the field order in Link, which may temporarily suppress the current error.
However, since Lead is being defined first in this case, the table structure for Business ends up being inaccurate.

type Link struct {
	IDField
        LeadRelation
	AgentRelation


        // other fields
}

I’ll try to resolve this issue, but it will likely take some time. At the moment, I haven’t come up with a viable solution.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. If there is no update within the next 7 days, this issue will be closed.

[mkocztorz]

Hi @j2gg0s!
Do you have any news?

[j2gg0s]

I’m sorry, but I don’t have time to handle it in the short term.

On one hand, I’m currently focused on inference optimization for image models and can’t spare the effort elsewhere.
On the other hand, based on my initial assessment, I feel that this issue may not have a perfect solution.

[mkocztorz]

Thanks! Not really rushing you as I understand this is complex. Github actions bot threttened to close this issue if there is no activity though.