BoxLang: bulkOperationsSpec type assertions reject BoxLang-classed model instances

[bpamiri]

Describe the bug

wheels.tests.specs.model.bulkOperationsSpec asserts that the values returned from insertAll() / updateAll() / friends are of type "component". On BoxLang the assertion fails with:

The actual is of type [wheels.tests._assets.models.BulkItem] which is not the expected type of [component]

BoxLang reports the FQN of the class, not the generic component type that Lucee/Adobe use.

Evidence

Compat-matrix run #25837380625 (2026-05-13).

• 8 occurrences on BoxLang across cockroachdb, mysql, postgres, sqlite.
• Plus a sibling cluster of 4 occurrences with [wheels.tests._assets.models.Author] instead of BulkItem — same root cause.
• Lucee/Adobe pass cleanly.
• Affected suites (all in bulkOperationsSpec): insertAll, updateAll, related — wherever expect(record).toBeTypeOf("component") appears.

To Reproduce

1. Hit /wheels/core/tests?db=sqlite&format=json&directory=tests.specs.model.bulkOperationsSpec on BoxLang.
2. Any spec containing toBeTypeOf("component") (or equivalent) on a model instance errors with the message above.

Expected behavior

The assertion should accept any Wheels model instance as "a Wheels component" regardless of how the underlying engine reflects the class metadata.

Root cause

CFML engines differ on how getMetadata(obj).type / WheelsTest's toBeTypeOf resolve class identity:

• Lucee / Adobe → returns "component" for any CFC instance.
• BoxLang → returns the fully-qualified class name (e.g. wheels.tests._assets.models.BulkItem).

The spec is using the wrong assertion shape for cross-engine work. There's no portable way to assert "this is a CFC" via the literal "component" string.

Suggested fix shape

Replace toBeTypeOf("component") with one of:

1. toBeInstanceOf("Model") — most semantically correct; checks against the Wheels Model base class.
2. expect(IsObject(record)).toBeTrue() — most permissive; just confirms it's an object.
3. expect(IsInstanceOf(record, "Model")).toBeTrue() — alternative shape.

Pure test edit — no framework changes. Estimated <10 minutes for one experienced contributor.

Additional context

• Part of the Core test suite has high failure/error rate on BoxLang (35 failures, 125 errors, 3526 passing) #2649 decomposition (Tier 2).
• Same lesson applies as the getResponse() adapter issue in BoxLang: getStatusCode() throws — adapter getResponse() override breaks Base.cfc lookup #2659: engine-introspection APIs are not portable. Avoid assertions that depend on what getMetadata() returns; assert on behavior or use IsInstanceOf against the framework's base classes.
• Worth adding to .ai/wheels/cross-engine-compatibility.md under a "type-check assertions" section: "Use IsInstanceOf(x, 'BaseClass') rather than getMetadata(x).type == 'component'; the latter returns the FQN on BoxLang."

Related: #2649

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

model — see .ai/wheels/model/ and .ai/wheels/testing/ for canonical patterns. The defect lives in the model test spec at vendor/wheels/tests/specs/model/bulkOperationsSpec.cfc (lines 78 and 98), where expect(found).toBeInstanceOf("component") is asserted against a CFC returned by findOne().

Fix sketch

Replace the two toBeInstanceOf("component") calls in vendor/wheels/tests/specs/model/bulkOperationsSpec.cfc with a portable assertion. The cleanest shape is toBeInstanceOf("Model") — every Wheels model extends the framework's Model base class, and IsInstanceOf walks the inheritance chain on Lucee, Adobe, and BoxLang. Alternatives (expect(IsObject(found)).toBeTrue()) are valid but weaker. Pure test edit; no framework change. Worth a short follow-up note in .ai/wheels/cross-engine-compatibility.md calling out that getMetadata(x).type == "component" is a Lucee/Adobe-only idiom and that IsInstanceOf against the framework base class is the portable check.

Confidence: medium

Fix shape is mechanical and obvious, but auto-downgraded to medium per the cross-engine rule — BoxLang vs Lucee/Adobe behavior diverges on getMetadata().type, so the propose-fix stage should verify the chosen assertion ("Model") resolves correctly across all three engines before opening the PR.

<!-- wheels-bot:triage:2662 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2667

Spec: vendor/wheels/tests/specs/wheelstest/ExpectationToBeWheelsModelSpec.cfc — failing → passing (failing first proven: The dynamic/static method: toBeWheelsModel does not exist in this class)
Implementation: vendor/wheels/wheelstest/system/Expectation.cfc (new toBeWheelsModel() matcher), vendor/wheels/tests/specs/model/bulkOperationsSpec.cfc (assertions routed through the new matcher)

Local Lucee 7 + SQLite verification:

• wheels.tests.specs.wheelstest → 125 pass / 0 fail / 0 error (4 new specs)
• wheels.tests.specs.model → 810 pass / 0 fail / 0 error (no regressions)

BoxLang × cockroachdb/mysql/postgres/sqlite verification depends on the compat-matrix run that this PR triggers — local BoxLang setup is not available in the bot's environment, but the chosen assertion shape (IsInstanceOf against Model base class) walks the inheritance chain identically on Lucee, Adobe, and BoxLang, so no engine-conditional code is needed.

A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.