Bug: this.relationField resolves against collection model inside auth().collection?[...] predicates

[hechang27-sprt]

Description

Inside an access policy collection predicate on auth(), the this keyword resolves scalar fields against the @@allow model correctly, but resolves relation fields against the collection's model instead — contradicting the docs and breaking scope-tree RBAC patterns.

Reproduction

Minimal ZModel:

model ActorContext {
  id           String @id
  capabilityGrants DerivedCapabilityGrant[]
  @@auth
}

model DerivedCapabilityGrant {
  id             String @id
  actorContextId String
  capabilityKey  String
  grantScopeId   String
  grantScope     AuthScope @relation(fields: [grantScopeId], references: [id])
}

model AuthScope {
  id        String    @id
  path      String[]
  documents DocumentBase[]
}

model DocumentBase {
  documentId  String    @id
  tenantId    String
  authScopeId String
  authScope   AuthScope @relation(fields: [authScopeId], references: [id])
  
  @@allow('read',
    auth() != null &&
    auth().tenantId == tenantId &&
    auth().capabilityGrants?[
      capabilityKey == 'read' &&
      (grantScopeId == this.authScopeId || grantScopeId in this.authScope.path)
    ]
  )
}

The ZModel parser accepts grantScopeId in this.authScope.path at generation time. But at runtime, the policy engine crashes:

Error: Field "authScope" not found in model "DerivedCapabilityGrant"

Stack trace:

ExpressionTransformer.transformRelationAccess (expression-transformer.ts:837)
ExpressionTransformer._member (expression-transformer.ts:705)

Expected Behavior

According to the docs, "the keyword this can be used inside the CONDITION to refer to fields belonging to the model where the rule is defined (the outer model)."

So this.authScope.path inside auth().capabilityGrants?[...] should resolve:

1. this → DocumentBase (the model with @@allow)
2. this.authScope → DocumentBase.authScope relation
3. this.authScope.path → AuthScope.path

Actual Behavior

The engine resolves authScope against DerivedCapabilityGrant (the collection's model), which doesn't have that field.

Workaround

1. check() delegation to AuthScope's @@allow (which doesn't suffer from this issue since this resolves correctly in top-level or check-based predicates)
2. Denormalizing the relation field into a scalar array (e.g., scopingPath String[] on DocumentBase) and checking grantScopeId in this.scopingPath

Environment

• ZenStack version: 3.8.0
• Provider: PostgreSQL (PGLite but I doubt that caused this bug)
• ZenStack CLI: zen generate
• ORM client

Notes

• Scalar fields on this work correctly (e.g., grantScopeId == this.authScopeId passes)
• Relation fields on this behave identically with and without binding variables ([g, ...])
• The failure is at runtime (expression-transformer.ts:837), not at parse time — the ZModel parser accepts the syntax

[hechang27-sprt]

Confirmed the bug also exists in 3.7.2 (not a 3.8 regression). Same exact failure: Field "authScope" not found in model "DerivedCapabilityGrant" at expression-transformer.ts:831 in 3.7.2.

[hechang27-sprt]

Root Cause Analysis

The bug is in transformRelationAccess at expression-transformer.ts:843:

private transformRelationAccess(
    field: string,
    relationModel: string,
    context: ExpressionTransformerContext,
): SelectQueryNode {
    const fromModel = context.modelOrType;  // <-- BUG: should use context.thisType for `this.`-prefixed fields
    const relationFieldDef = QueryUtils.requireField(this.schema, fromModel, field);

Here's the call chain:

1. transformCollectionPredicate (line 408) sets modelOrType to the collection's model (DerivedCapabilityGrant) when transforming the predicate body:

   this.transform(expr.right, {
       ...context,
       modelOrType: newContextModel,  // set to DerivedCapabilityGrant
   });

2. context.thisType is correctly preserved as the @@allow model (DocumentBase)

3. _member (line 692-705) correctly identifies this. prefixes and uses context.thisType to resolve the first field:

   if (ExpressionUtils.isThis(expr.receiver)) {
       const firstMemberFieldDef = QueryUtils.requireField(this.schema, context.thisType, expr.members[0]!);
       receiver = this.transformRelationAccess(expr.members[0]!, firstMemberFieldDef.type, restContext);
   }

4. But transformRelationAccess at line 843 uses context.modelOrType (which is still DerivedCapabilityGrant), not context.thisType (DocumentBase). This causes the relation authScope to be looked up on the wrong model.

The fix: transformRelationAccess needs to know whether the field is being resolved from a this.-prefixed expression and use context.thisType accordingly. Or _member should set modelOrType to thisType in restContext when passing to transformRelationAccess.

Related: getFieldDefFromFieldRef (line 1003) correctly handles this case — it uses thisType for this. fields and modelOrType otherwise. transformRelationAccess was not updated with the same logic.

[hechang27-sprt]

Confirmed Fix

The fix is a one-line change at the _member method in expression-transformer.ts (source line 705 / dist line 526):

Before:

receiver = this.transformRelationAccess(expr.members[0], firstMemberFieldDef.type, restContext);

After:

receiver = this.transformRelationAccess(expr.members[0], firstMemberFieldDef.type, { ...restContext, modelOrType: context.thisType });

This ensures transformRelationAccess uses thisType (the @@allow model) instead of modelOrType (the collection's model) for this.-prefixed relation fields. The _member method already correctly resolves the field definition against thisType (line 704), but then passed the wrong context to transformRelationAccess.

Tested with dist patch - the Field "authScope" not found in model "DerivedCapabilityGrant" error is eliminated. The policy now generates the correct SQL:

$14 = any((select "path" from "public"."AuthScope" where "DocumentBase"."authScopeId" = "AuthScope"."id"))

Note on PGlite

PGlite (SQLite-based) doesn't handle ANY(array_subquery) correctly - it throws malformed array literal. This is a PGlite limitation, not a ZenStack issue. Real PostgreSQL handles it fine. Nononno, Bad AI, no halucination...